httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Fri, 12 Apr 2002 00:59:11 GMT
On Thu, Apr 11, 2002 at 05:19:36PM -0700, Roy T. Fielding wrote:
> It doesn't cause a ceiling -- it causes the M+1 request to go hang out in
> limbo when it could have been processed by the other child.  This isn't 
> only
> likely, it will happen consistently on any server that handles more than
> M requests per second on a regular basis.  Any high-end site.

OK, I think I've just realized something. When I was working on the worker
MPM I tested all these kinds of scenarios, with both ab and flood and
I never ran into what we're seeing now. I have a theory:

Back then we had the POD and at least one listener, which essentially
caused us to never use S_L_U_A, meaning we always had an accept mutex.
Now that that's been corrected, the problem with the "we can accept
more connections than we can immediately process" is showing up because,
as you said (below), the OS is electing the accept() call from the
same process before migrating to another process.

A simple way to check if this is true is by adding a second Listen
directive and see if the problem goes away.

[...]

> What do you mean by "worst case"?  That is almost every case.  You are
> forgetting that the child has LIFO characteristics, which means it will
> handle every request until the M+1 arrives.

Not exactly, not unless you're talking about the OS and not the worker
design. That is not what LIFO means to the worker. If you have an accept
mutex then the election over that mutex determines which child will
call accept.

> Furthermore, you are assuming
> that request arrival rates are normally distributed, which simply isn't
> the case.

I stated that assumption. I don't know what kind of distribution we're
getting, but I can assure you that when I did my load tests on the
worker MPM it was very nicely balanced between the child processes,
even in the extreme case (few ThreadsPerChild, many Children).

> What will happen in the real case is a single child will
> accept connections from a sequence of M/4 or so clients until its threads
> are busy, and the last client will have one of its requests stuck waiting
> for the other threads to be finished with serving a slow client or simply
> waiting in lingering close or simply writing the log file.  In other words,
> one in every M/4 clients will encounter two or three seconds of additional
> latency because the MPM is broken.

Was this by observation? Can you tell me what version this is? Did you
have S_L_U_A?

[...]

-aaron

Mime
View raw message