At 08:11 AM 6/17/2005, Akins, Brian wrote: >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.
No, it doesn't :) But lowering the keepalive threshold to three to five seconds does. We are lowering the 'example' keepalive timeout in the next releases. Keepalives as originally implemented were to help users with loading additional images (and now, css stylesheets.) And the time was set to allow a user to grab 'another page' if they quickly clicked through. But the later use is not a good use of child slots, and the former use case has a -much- lower window these days, as most browsers are quite fast to compose the base document and determine what images are required. With the relative disappearance of 1200baud dialup, 15 seconds for the client to sit and think about grabbing more documents to compose the current page is very silly :) >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. > >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? I am willing to write the code if this seems desirable. Should >this just be another module or in the http core? If you experiment with setting the keepalive window to 3 seconds or so, how does that affect your test? Also, I'd be very concerned about additional load - clients who are retrieving many gifs (with no pause at all) in a pipelined fashion will end up hurting the over resource usage if you force them back to HTTP/1.0 behavior. Bill
