httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Apache 2.0 for Windows update
Date Wed, 20 Oct 1999 14:47:41 GMT
I've been doing some performance work in Apache 2.0 for Windows. I've made a
lot of little tweaks, but here are the big ones:

1. Implemented asynchronous AcceptEx with worker threads blocked on an
AcceptEx completion port.
The worker threads are dispatched LIFO (I can see this in profiling), which
is goodness. This work is checked into the Apache 2.0 repository.

2. Implemented a version of ap_send_fd which will use TransmitFile under the
covers. I had to add the sendfile method to the iol then implemented it in
os/win32/iol_socket. I plan to implement iol_socket (Unix and Windows) using
APR calls, but this is going to take a good bit of work to complete.  This
will work with other OSes which support sendfile. Not checked into the
repository.

3. Modified mod_mmap_static to cache file handles on Windows.
I burned a day and a half on this one, even though the code changes were
minimal. Turns out that the file needs to be opened for overlapped I/O if
multiple threads are going to issue TransmitFile on it.  If the file whose
handle is being placed in the cache is not opened for overlapped I/O, the
first TransmitFile suceeds but all the rest fail with EINVAL (10022). I
spent 98% of the time figuring this one out.  BTW,  the changes to
mod_mmap_static to cache file handles should work for any system that
supports the API.  Not in the repository yet.

The client is ApacheBench running on a 450Mhz PII running RH Linux (5.2 +
kernel updates)
    ab -n 10000 -c 30 10.0.0.1/file500.html  fetchs a 500 byte file.

Apache 1.3 serves around 400 cps with this test. Apache 2.0 with the above
modifications serves around 730 cps. I haven't tested it, but I suspect
Apache 2.0 for Windows will scale well with increasing number of clients
too. Client scaling is actually more important than raw speed. I'll do some
client scaling tests after I fix all the places where the winnt MPM doesn't
check return codes :-)

Some random comments:
I would expect Apache 2.0 to be even faster relative to Apache 1.3 as the
file size increases.  sendfile API's really are most beneficial on large
files.  Caching file handles rather than MMAPed file should allow us to
cache a very large working set w/o using significant amounts of system
resources. We can get quite fancy with the file handle cache too. For
example, it is possible on Windows to register a callback function to be
called when a file on disk changes. If a file changes, the callback could
garbage collect the cached handle. We could also make the cache dynamically
load itself as the server runs, filtered config directives (design anyone?).

The AcceptEx call takes two socket descriptors. A listen socket and an
accept socket. The easy way of handling this is to open a new accept socket
prior to each call to AcceptEx. That's what I am doing in the winnt MPM now.
There is another performance improvement possible by reusing accept sockets
(i.e., disconnecting but not closing them after a request is processed).  I
am not sure how to exploit this and still use keep-alive sessions and handle
connections that are not served via TransmitFile (TF has options
specifically designed to allow you to reuse connections. Not sure if you can
reuse connections that do not use TF...).

Overall, the Windows port is shaping up quite nicely. With APR, it will be
relatively easy to implement things like piped logs now. A lot of Windows
specific code in the server has been eliminated (just take a look at the
changes related to getting mod_cgi working in Apache 2.0). It is much
cleaner.

There is still a load of work before we can consider a beta, though. The mpm
needs to be made to run in non-debug mode, it needs much more error
checking/handling code, all the code related to running the server as a
service needs to be integrated back in, APR implementations need to be
cleaned up. iol_socket routines need to be migrated to APR (the Win32
iol_socket implementations of read/write, et.al are beter than the
implementations in APR)

Bill




Mime
View raw message