Re^2: Why can code be so slow?

As soon as I am fully done, out of my featurefreeze and fixed most bugs I will probably move to Apache2 and more even to Mod_Perl2 ; probably with Apache::Registry to start with (any reasons why I shouldn't?)

Still now it would need to be increased in performance; it cannot be Apache 1.3 gives this pisspoor performance with Perl ; I would be more happy if I'd be getting like 16 or more hits / second instead of under 1 request / sec. ;)

If I'd get 16r/sec I could probably get 10x more with mod_perl; so I can better get it better now and optimize it even more with mod_perl and checking my algorithms for any "hidden delays"..

Comment on Re^2: Why can code be so slow?

Replies are listed 'Best First'.
Re^3: Why can code be so slow? by jbert (Priest) on May 02, 2007 at 16:15 UTC
What people are saying about using mod_perl is that it will remove the effect of perl startup time from your application. You can try to measure the effect of startup time by something like the following: #!/usr/bin/perl use warnings; use strict; use Time::HiRes; my $hr_log; BEGIN { open($hr_log, ">", "/tmp/hrlog") or die "can't open hi-res log"; sub hr_logger { my ($secs, $msecs) = Time::HiRes::gettimeofday(); print $hr_log "$secs.$msecs: ", join("\|", @_), "\n"; } hr_logger("BEGIN"); } # Obviously, you'll have all your modules here use CGI; # Put this just before you actually do any work in your code # i.e. after all your 'use' lines hr_logger("Ready to run"); # This bit would be your app print "Now get on with running the app\n"; # And put this before you exit, for completeness hr_logger("finished"); exit 0; [download] which on my system produces the output: `1178122211.615440: BEGIN 1178122211.646999: Ready to run 1178122211.647111: finished` [download] In my case above, the 'use CGI' time dominates, because I'm doing nothing in the app. If you do the same, but sprinkle a few more calls to hr_logger in your code, then you should be able to work out what is slow. From what you've posted so far, it sounds as though you are parsing a lot of XML. If you need to do this parse per-request, then mod_perl won't speed you up much (and you'll need to look into optimising your XML use or replacing it with something else). If you only need to do this parse on startup, then mod_perl (or FastCGI) would help you. It's not really a case of getting this optimised and then getting another speed boost by moving to mod_perl. What mod_perl does is save you startup costs. Profiling and optimising your existing code will save your per-request costs. They're pretty indpendent really and you want to know which is hurting you since you don't want to waste your time optimising the areas which aren't hurting you.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Why can code be so slow?
by jbert (Priest) on May 02, 2007 at 16:15 UTC

You can try to measure the effect of startup time by something like the following:

#!/usr/bin/perl
use warnings;
use strict;
use Time::HiRes;
my $hr_log;
BEGIN {
    open($hr_log, ">", "/tmp/hrlog")
        or die "can't open hi-res log";
    sub hr_logger {
        my ($secs, $msecs) = Time::HiRes::gettimeofday();
        print $hr_log "$secs.$msecs: ", join("|", @_), "\n";
    }
    hr_logger("BEGIN");
}
# Obviously, you'll have all your modules here
use CGI;

# Put this just before you actually do any work in your code
# i.e. after all your 'use' lines
hr_logger("Ready to run");

# This bit would be your app
print "Now get on with running the app\n";

# And put this before you exit, for completeness
hr_logger("finished");
exit 0;
[download]

1178122211.615440: BEGIN
1178122211.646999: Ready to run
1178122211.647111: finished
[download]

If you do the same, but sprinkle a few more calls to hr_logger in your code, then you should be able to work out what is slow. From what you've posted so far, it sounds as though you are parsing a lot of XML.

If you need to do this parse per-request, then mod_perl won't speed you up much (and you'll need to look into optimising your XML use or replacing it with something else). If you only need to do this parse on startup, then mod_perl (or FastCGI) would help you.

It's not really a case of getting this optimised and then getting another speed boost by moving to mod_perl. What mod_perl does is save you *startup costs*. Profiling and optimising your existing code will save your per-request costs. They're pretty indpendent really and you want to know which is hurting you since you don't want to waste your time optimising the areas which aren't hurting you.

[reply]
[d/l]
[select]