How much overhead in msec

[david_kw]

I was wondering if anyone has experience with cgi perl scripts in ajax not using mod_perl. Using Firebug, it claims there is a 700ms+ time to get the response for a 400 line script (uses DBI, CGI, among other libraries).

Then just using a small script that does use CGI and basically just returns the header it takes 300ms+. With just print statements and no libraries it takes about 100ms.

I admit I don't have a fast server, but are those expected numbers? Is mod_perl significantly faster? Is mod_perl as scary as it seems? (I see a 1000 page book on amazon) And one more question where this might not be the right forum to ask :) but is another language (PHP, Ruby, etc) better in time critical ajax responses?

I guess my main question is, does 300ms sound typical for the return of a simple script from perl? Or might I have a configuration problem?

Thanks,
david_kw

[ralph l mayo]

I admit I don't have a fast server, but are those expected numbers?

I haven't bothered testing this because I've never had an AJAX app where latency was a concern. 700ms sounds high, but it's CGI and it has to do a whole bunch of preparation for every request it could cache and skip on nearly every request.


Is mod_perl significantly faster?

Yes. Here's some stuff I took from the mod_python documentation because I remember seeing the comparison there, but I believe the ratios are similar for mod_perl (note it's thoroughput and not latency but due to the caching/read-once-use-many-time thing mod_perl does latency will improve similarly):

Standard CGI: 23 request/s
cgihandler: 385 request/s # <-- mod_perl has something like this, I believe Apache::Perl-Run? It runs legacy CGI scripts with caching but without some important optimizations
publisher: 476 request/s # <-- mod_perl here is Apache::Registry, I don't have any experience with this but it's for well-behaved CGI scripts on their way to the next level:
native handler: 1203 request/s # <-- this is where you configure your module with a handler() to take a request object directly from Apache without the intervention of a compatibility layer like Registry or PerlRun


Is mod_perl as scary as it seems? (I see a 1000 page book on amazon)

No, it's really easier once you've had a bit of work with it. CGI is basically a whole layer of complexity mod_perl obviates by giving you direct access to the Apache API.

As you can see above, just moving to mod_perl from CGI and using Perl-Run to run your unmodified scripts can net you an order of magnitude in speed (*YMMV, you always have to bench and profile these things)

As for the thousand page book, forget it. I love to buy tech books and the only thing I ever got for this is the O'Reilly mod_perl pocket reference, which is just a convenient listing of docs you can find on the first few google results for mod_perlish things and comes in at 83 booklet-sized pages with indices and the lengthy beginner's preamble.

FastCGI is another thing to look at in speeding up legacy CGI, but it's not at all preferable to mod_perl and its potential gains are capped around the Perl-Run level.


And one more question where this might not be the right forum to ask :) but is another language (PHP, Ruby, etc) better in time critical ajax responses?

mod_python is screaming fast these days. It caches bytecode like Java but doesn't have Java's huge VM overhead. I doubt you're going to find a faster web-oriented technology right now. That said, mod_perl is very quick. My personal go-to for all things web, Ruby, ranks between mod_python and mod_perl, and all of them are quicker than PHP.

You can poke around http://shootout.alioth.debian.org/ to see how things compare, but keep in mind that benchmarks aren't necessarily or even often an indication of the performance of your actual implementation.



I guess my main question is, does 300ms sound typical for the return of a simple script from perl? Or might I have a configuration problem?
Yes, I'd say the configuration problem is using CGI.

another thing to consider: Inlining C can do wonders for an app written in a really high level language like perl. I've been going through a ruby app, profiling and re-writing bottlenecks in C++ and have seen incredible improvements. Perl, Python, and Ruby can all do this relatively painlessly.

[david_kw]

Very interesting. Thanks for the response. I'm looking for a server side solution now that cgi perl doesn't seem to be the answer. I looked at Ruby but I have to admit after years of C, C++, C#, JavaScript, Java, Perl, etc I am sort of hooked on the C programming structure. Looking at Ruby was completely different. Still if it has the hand over everything else I might have to go that way.

I read a bunch of articles and looked at what internet companies seem to be using (browsing technical requirements for new hires) and it seems like a lot of companies are using jsp. I've done java with applets but have little experience in it serverside. I might have to download Tomcat and do some tests.

Thanks again for confirming my worries about using CGI perl. Not a long term solution the way I'm using it apparently.

david_kw

[FishMonger]

Besides the differences between each language and whether you're using CGI, mod_perl, mod_python, php, or what ever, you also need to look at the implementation. I can write 3 (or more) Perl scripts/programs that process the same data and return the same results in the same format but each could/would take vastly different amounts of time. When I was taking my “Intro to Perl Programming” class, one of the, more complex, class assignments that I turned in took almost a week to work out and I was proud that I was able to get the processing down to 7 minutes. Alas, the proper/best solution took less than 30 seconds.

The point I'm getting at is that you need to post your script and ask specific questions regarding its implementation before we can say if there is a better/faster way of doing “it”.

[david_kw]

Fair enough. Here is a script that I tested using AJAX and FireFox 2 with Firebug for profiling.


#!/usr/bin/perl

use strict;
use warnings;

use CGI;

my $q = new CGI;

print $q->header(-type => "text/plain");


According to Firebug it takes approx 300ms round trip for this request. Should I expect that? For reference, a 7.5k javascript file took 31ms to load (not in ajax, but during the loading phase of the site). Again, this isn't using mod_perl but straight cgi. If so, would changing to mod_perl give an order of magnitude increase in speed?

david_kw

[ralph l mayo]

david, using CGI means the perl interpreter is loaded and asked to interpret your file from scratch every time. With mod_perl your apache child processes already have the interpreter in memory (they take up more ram right off the bat but it's a very good memory->speed tradeoff) and they can remember what the loaded libraries entail and don't have to hit them ever request. I'm looking through the libs in Ubuntu now and using CGI entails 7623 lines of code, and it also pulls in Carp at 100 lines, which in turn pulls in Exporter at about the same. (Also, in an unrelated note, Exporter has use strict commented out, WTF?)... so in any event, 8k lines to reconcile per request. 300ms is reasonable to the point of being admirable. And it's round trip, so network latency accounts for ~1/3 of that?

As for JSP, yeah a lot of companies use that, and .NET, with an Oracle backing, the usual suspects. Not that there's anything so wrong with any of these technologies but if you're looking strictly at adoption figures you have to consider the buy-in to the ridiculous "Enterprise" dogma that plagues corporate tech decisions. In my experience with Java I've found it to be little more than a less expressive and less efficient version of C++. /slightly OT holywar bait