Bill Stoddard wrote:
If the event MPM is working properly, then a worker thread should not be
blocking waiting for the next ka
request. You still have the overhead of the tcp connection and some
storage used by httpd to manage connection
events but both of those are small compared to a blocking thread.
Should there be an upper limit on how many connections to have in
keepalive, even when using event? Say you have 100 worker threads, you
wouldn't want to have 8192 keepalive connections. So you would want
some limit.
Both approaches sound pragmatic (+.5) although I would like to think the
best long term solution is to
completely decouple TCP connections from worker threads.
I really like the event mpm, but I still think there has to be an upper
limit on how many connections to allow to keepalive.
is an experiment in that direction but
it still has a long ways to go. Earliest I could see this happening is
in the v 2.4 timeframe.
We've been doing some testing with the current 2.1 implementation, and
it works, it just currently doesn't offer much advantage over worker for
us. If num keepalives == maxclients, you can't accept anymore
connections. I want to be able to limit total number of keepalives.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
