httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akins, Brian" <Brian.Ak...@turner.com>
Subject Is async the answer?
Date Fri, 18 Jan 2008 17:03:02 GMT
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


Mime
View raw message