This is just some ramblings based on some observations, theories, and tests. Partially "devil's advocate" as well.
Most of us seem to have convinced our self that high performance network applications (including web servers) must be asynchronous in order to scale. Is this still valid? For that matter, was it ever? We just ran a large scale test on a busy website (won't mention the name...) and ran about 95% of production traffic on a single server. This was about 30k connections. We set maxclients to 50k. Server did fine, had about 4GB Ram free and 55% cpu idle. This was the full production config, not stripped down or anything, using our cache and proxy and several "stock" modules. Granted these were fairly "beefy" servers, but nothing extraordinary: 2xdual core 2.4 Ghz CPU's with 8GB RAM, normal non-TOE Ethernet (but with checksum's on card). It seems that modern OS's (this was Linux 2.6.something) deal with the "thread overhead" and all the context switches very well. All the stuff mentioned in the "the c10k problem" ( http://www.kegel.com/c10k.html) didn't seem to apply. We could have easily doubled the amount of connections to the server, I think. We were using normal worker MPM with keepalives for this test. The current "stable" event would have helped with idle keepalive threads, but the system didn't seem to care. Response time never increased in any measurable amount. Yes, we are using sendfile, mmap, etc., so zero-copy helps us a lot. So, do we need apache 3 (or whatever it's called) to be fully asynchronous? Is that just us reacting to "the market" trends, ie, lighttpd? All the apache httpd "is bloated and slow" is just plain horse crap. It's not that hard to configure apache to be "fast." C programming is my "hobby," and it's not that hard to write modules that don't do stupid things and kill the performance. The biggest thing we do in our modules is to make trade-offs to avoid locking. Ie, we are happy to "waste" a few MB of RAM with some "per-module scoreboards" than to use per-proc or global locking. Most of our counters are per thread, and we just add them up when someone access the counter (ie, via mod_status). This made a huge difference in our performance. Also, don't get in httpd's way. Let the core handlers handle as much as possible. Just "encourage" them when needed. They are battle tested and improvements made there help everything out if you haven't tried to rewrite it in your own module. Like I said, just some ramblings. We may experiment with the current event MPM some more, but I honestly do not see the huge benefit to moving to a fully async IO architecture. It's very easy to write modules in the current "one thread per request" model. People will screw up the async thing and make it slower anyway, probably. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
