httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: Keepalives
Date Fri, 17 Jun 2005 14:23:50 GMT
Akins, Brian wrote:
> Here's the problem:
> If you want to use keepalives, all of you workers (threads/procs/whatever)
> can become busy just waiting on another request on a keepalive connection.
> Raising MaxClients does not help.
> The Event MPM does not seems to really help this situation.  It seems to
> only make each keepalive connection "cheaper."  It can still allow all
> workers to be blocking on keepalives.

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.

> Short Term solution:
> This is what we did.  We use worker MPM.  We wrote a simple modules that
> keep track of how many keeapalive connections are active.  When a threshold
> is reached, it does not allow anymore keepalives.  (Basically sets
> r->connection->keepalive = AP_CONN_CLOSE).  This works for us, but the 
> limit
> is per process and only works for threaded MPM's.
> Long Term solution:
> Keep track of keepalives in the scoreboard (or somewhere else). Allow
> admin's to set a threshold for keepalives:
> MaxClients 1024
> MaxConcurrentKeepalives 768
> Or something like that.
> Thoughts?  

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. The event MPM 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.


View raw message