Re: Keepalives

[Bill Stoddard]

Brian Akins wrote:
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.  
Interesting point; it's been a while since I looked at the event MPM but I thought (mistakenly) that 
maxclients accounting was adjusted to reflect max number of concurrently active worker threads rather than 
active tcp connections. I agree we need some kind of upper limit on the max number of TCP connections into a 
running instance of httpd, regardless of whether those connections are associated with a worker thread or not.

Bill