httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: core_output_filter buffering for keepalives? Re: Apache 2.0 Numbers
Date Mon, 24 Jun 2002 05:15:56 GMT

> On Sun, 2002-06-23 at 20:58, Brian Pane wrote:
> > For what it's worth, I just tried the test case that you posted.  On my
> > test system, 2.0 is faster when I run ab without -k, and 1.3 is faster
> > when I run with -k.
> I studied this test case and found out why 2.0 runs faster in the
> non-keepalive case and slower in the non-keepalive case.  It's
> because of the logic in core_output_filter() that tries to avoid
> small writes when c->keepalive is set.

This is part of the opimization for handling pipelined requests.  If requests are
pipelined, then this is a good optimization, otherwise we are burning a system call. On
some systems (Linux), this is not a big deal. AIX and Win32 (and I suspect Solaris) reads
that return EAGAIN burn a lot of time. System calls look like this when serving a 500 byte
file (or, I think, any file less than AP_MIN_BYTES_TO_WRITE).

read()  /* ap_read_request - read request */
read()  /* check for pipelined request. Typically get EAGAIN on this read */
write() /* send the content. may be sendfile */
read()  /* ap_read_request, in my tests this generally returns EAGAIN */
select() /* wait for next keep alive connection */

So we have two extra system calls here.  I just set AP_MIN_BYTES_TO_WRITE to 499 and get
the following:

read()  /* ap_read_request - read the request */
write() /* write the 500 byte file */
read()  /* out of check_pipeline_flush. More pipeline request optimization. Returns EAGAIN
read()  /* ap_read_request(). Typically returns EAGAIN */
select() /* wait for next keep alive */

So changing the AP_MIN_BYTES_TO_WRITE just moves the relative postion of the write() and
the check pipeline read.

Some potential low hanging fruit here... would it make sense to make the keepalive read
(the one right before the select) an APR_INCOMPLETE_READ?


View raw message