"good" is kind of relative here.

it depends on things like your CPU speed, disk speed, bandwidth, how much work each request is doing and how much data is being served. 8.8 hits a second sounds pretty good. if each of those hits involves multiple database queries and sending out a 100K page, that's obviously better than handling 8.8 HEAD requests.

the real question is whether it's enough for your site. check your logs. are you getting more or less than 8.8 hits/second? that's your answer.

anders pearson

It seems very low. This might be because of memory constraints on the server - each apache child ends up with a copy of Perl running inside it, so the system might end up swapping a lot. I consider mod_perl to be a hack and an inelegant solution; if your have 200 people on 56k modems downloading files slowly that's 200 apache processes, which contain 200 perl processes.

IMHO a far more elegant solution is that provided by FastCGI, or SpeedyCGI. With these solutions your cgi scripts are turned into daemon processes that listen on sockets for connections from your web server children. The Perl process quickly spits out the response, and is in the middle of a loop so is very quick. The drawback is that for optimum efficiency you should reduce all of the CGI scripts on your site into one big script.

With FastCGI especially, the web server becomes about as busy as it was serving flat files, so the amount you can serve will increase by an order of magnitude or more.

srand 3.14159; print join("",sort
{rand 1<0.5}map{$_^"\037"}split m{
}x,"qmptk|z~wOzm??l]pUqx^k?j"),",\n";
[download]