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.
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.
I'm pleased to hear you've tried the event mpm.
not sure why there has to be a limit. are you talking about connections per
worker process? except for the size of the pollset, I didn't see a need to put
a limit on the number of connections per worker process back when I was stress
testing it with specweb99. when a worker process was saturated with active
threads, the listener thread would block in ap_queue_info_wait_for_idler() until
a worker thread freed up. in the mean time, other processes would grab the new
connections. so it was sort of self balancing as far as distributing
connections among processes.
not sure if the current code still behaves that way. I plan to find out soon
though.
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.
that's a surprise, and it sounds like a bug. I'll investigate. it used to be
that maxclients was really max worker threads and you could have far more
connections than threads.
thanks for the feedback.
Greg
