measuring startup time: how early does $^T (start time of program) get set?

blahblahblah has asked for the wisdom of the Perl Monks concerning the following question:

I work on a very large web application written primarily in perl. We're currently looking at ways to improve performance for larger numbers of users. It's plain old cgi, not mod_perl. We know that moving to mod_perl would help a lot, but it's a huge job and we want to get an idea of how much it will really help.

I'd like to know how much time is spent parsing and compiling each of our scripts each time they're run. I had the idea that the first line of my program could call 'time' and subtract $^T from it. Does $^T get set early enough that this would give me reasonable data? From this test script, it seems like it might:

BEGIN
{
    print "BEGIN: $^T\n";
}
oh no!
[download]

The time is outputted before the compilation error.

I also thought about using the apache logs. I think I remember seeing a while ago that there's a way to record the total script time from there. I haven't looked into that yet. That would also hopefully include the overhead of apache starting a new process, so it might be more useful.

Any other ideas on measuring the startup overhead of running cgi scripts? Thanks.

Comment on measuring startup time: how early does $^T (start time of program) get set? Download Code

Replies are listed 'Best First'.
Re: measuring startup time: how early does $^T (start time of program) get set? by bart (Canon) on Mar 03, 2004 at 23:22 UTC
`$^T` is far too coarse for yoru kind of measurement, as it measures whole seconds only. If you want to measure compilation time, you can try something like this — put it near the very top of your script: `use Time::HiRes; my $t0; BEGIN { $t0 = Time::HiRes::time; } my $t1 = Time::HiRes::time; printf STDERR "Compilation time: %.3f seconds\n", $t1-$t0;` [download] $t0 is set in the BEGIN block, at the start of the compilation cycle. $t1 is set when the script actually starts to run, thus after compilation is complete. Next it prints out the difference, in fractions of seconds. This will still miss the startup time of perl itself.	[reply] [d/l]
Re: measuring startup time: how early does $^T (start time of program) get set? by tachyon (Chancellor) on Mar 03, 2004 at 21:32 UTC
This will not tell you what you want to know. The answer to which is about 20-40 times faster when you use mod_perl. You will get even more benefit if your scripts are connecting/disconnecting from a DB every call. When you call a CGI the first thing that happens is that the system has to start a new process ie it forks a perl binary. Once that is started your script is passed to it for compilation/execution. AFAIK perl sets $^T (not apache) so any number you get will be in a word - crap. The big overhead is forking the new perl - see Apache::PerlRun link below which essentially just gives you a persistent perl with the code recompiled on every call. This alone will give you 10x speed improvement on average. What you want is ab (apache benchmark, part of the apache distro). Set up a modperl environment. It is well documented and works smoothly. Put the same script into /cgi-bin and /modperl. Run ab. Read it and weep. You can run some pretty crap code using mod_perl with Apache::PerlRun which gives you a good chunk of mod_perl speed (ie persistent perl with no fork a new perl per call) but does not cache the code. In English this will turn dirty CGIs into dirty mod_perl widgets and get you 10x on speed with remarkably few, if any issues. cheers tachyon	[reply]