Stas,
I was looking over the latest version of the performance
section, and I have a few suggestions/comments regarding
http://perl.apache.org/guide/performance.html
1) Your description of keep-alive performance is confusing.
Every browser I've seen that implements keep-alives
will open at least 2 connections per server (HTTP/1.1 mandates
a max of 2, but 1.0 browsers like netscape open 3 or more). The
browsers are usually smart enough to round-robin the requests
between connections, so there's really no sequential delay.
Furthermore, HTTP/1.1 keepalive connections can be pipelined, to
make multiple requests on each connection without waiting for each
server response. In any real-world implementation, keepalives
are a clear winner over closed connections, even if they're
only left idle for a second or two.
Since most of us put a reverse proxy between the mod_perl server
and the browser; running keepalives on the browser<->proxy connection
is desirable.
I think your section on keepalives and their usefulness should include
some of the above comments. Recently I posted a patch for mod_proxy
to the mod_perl mailing list that enables keep-alives on the browser side;
I've also written a small Apache Perl module that does the same thing.
They also do store-and-forward on the request body (POST data), which
addresses an issue you raised in
http://perl.apache.org/guide/scenario.html#Buffering_Feature
...
There is no buffering of data uploaded from the client browser to the proxy,
thus you cannot use this technique to prevent the heavy mod_perl server from
being tied up during a large POST such as a file upload. Falling back to mod_cgi
seems to be the best solution for these specific scripts whose major function is
receiving large amounts of upstream data.
...
2) Apache::Request is better than your performance numbers indicate.
The problem I have with your comparison with Apache::args vs Apache::Request vs CGI
is that your benchmark code isn't fair. You're comparing method calls against
hash-table lookups, which is apples and oranges. To get more representative
numbers, try the following code instead
processing_with_apache_request.pl
---------------------------------
use strict;
use Apache::Request ();
my $r = shift;
my $q = Apache::Request->new($r);
$r->send_http_header('text/plain');
my $args = $q->param; # hash ref
print join "\n", map {"$_ => ".$$args{$_} } keys %$args;
and similiarly for CGI. The numbers you get should more accurately reflect
the performance of each.
HTH
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
