On 8/12/06, Qingshan Xie <xieq_49@xxxxxxxxx> wrote:
Joshua, I re-read your comment, have couple questions inserted below. Could you please help me again? Thx, Q.Xie --- Joshua Slive <joshua@xxxxxxxx> wrote: ...... > If the load-testing clients are not using > keep-alives, the server will > almost certainly be slower with keep-alives turned > on, because a bunch > of your processes will be stuck waiting for requests > on keep-alive connections that never come. I am not clear here. Since our load-test kept sending the requests continually, the children with keep-alive connections should not be stuck in waiting for requests. Am I right? still not clear why keep-alive slows down the performance? I also think, if the number of free/available children is big engough, a portion of children being stuck waiting for requests on keep-alive connections should not slow down the performance, right?
I don't know anything about your load testing tools. For example, is the client using keepalives? If not, turning them on on the server will certainly be slower. Even if the clients are using keepalives, how many requests are they sending per connection? Having a portion of children hanging out in keepalive could hurt even if there are children free, because it could cause more context switches/memory cache misses when switching requests between children.
> ...... A better solution in development in 2.2/2.3 > is the event mpm, which transfers keep-alive > processing to a separate thread where it doesn't tie > up the worker threads. Event mpm is really the one we are looking for. However, it seems still a experimental MPM. Could you tell me how stable event mpm in 2.2/2.3?
I believe it is relatively stable in 2.2 as long as you aren't using ssl. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|