> Some other performance issues that I've noticed:
> 0. It's using read rather than mmap to get the content
> from the files being delivered. Is this just a config
> error?
We use read if the file isn't large enough to make MMAP a good idea. This
is the same logic that Apache 1.3 used. How large is the file you are
trying to send? What platform are you on? What is APR_HAS_MMAP set to in
srclib/apr/include/apr.h?
> 1. On a request that results in a 304, the httpd does a
> gratuitous open/close of the requested file after stat'ing it.
That's bad.
> 2. There's also an extra read on the request socket just
> before the httpd sends the response, and another after
> the logger runs; both of these fail with EAGAIN. (I saw
> this with an HTTP/1.1 client that supports keepalives, so
> the last failed read was followed by a poll to wait for
> the next request on the socket.)
Have to look at those.
> 3. The amount of time spent reading/writing socket options
> after the accept is surprisingly large. (This time shows
> up under getsockopt, setsockopt, getsockname, and fstat64
> in the system call profile.)
David Reid has done some work on this, and I think he plans to commit it
soon-ish.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
