>> Not entirely true. It is possible. An Apache child could count the number
>> of children currently in use, and if it is the "last" one then it could
>> return a "too busy" error.
>Wouldn't those semantics be awfully restrictive? Imagine the situation
Yes. Restrictive can still be useful.
Quote:>where you have five children and five requests show up simultaneously
Presumably, the biggest use of this would be on servers with a large
number of connections. If you have a choice between having your
server hopelessly backlogging and between refusing some requests,
which do you think is better? Whichever it is, if you want to emulate
the IIS behaviour of only allowing x connections before giving a
"too busy" error, that can be done.
You also have to have a big enough number of child processes around
to make such anomolies statistically insignificant.
So if you have a MaxClients of 5 and have wild swings in traffic
(eg. a burst of 10 or 20 hits every 10 minutes), then this won't
work too well for you.
Quote:>In my mind, the only way to make sense of this request is to assume that
>busy means there's a delay between the TCP connection being established
>and a child accept()ing the connection. Unless I've missed something in
>the socket interface, there's no way to detect this. Furthermore, I
Right, but there is a metric you can use to guess at this. If your
server has no free child processes, then if you are in a steady
state over some period of time, either it is exactly at the point
of just barely being able to handle the requests or it is not able
to keep up. If it isn't able to keep up, even if it is only by a tiny
bit, the queueing delay will very quickly spiral out of control no matter
how little that bit is.
So if you ignore the "exactly what we can handle case", which is a
boundry case that doesn't really matter too much, and assume that you
have a steady state over a period of a few minutes (ie. one client making
5 requests at once isn't statistically significant, which really is
a valid experience on large sites) then not having a free child (ie.
current children == maxclients and they are all b usy) is a useful
metric to estimate if the queuing delay in your accept queue is large or
Quote:>assume the original question was how to send back a "too busy" message
>as soon as the connection was established if the listen queue was
>backlogged, which is not possible.
Except that by sending a small document that requires little processing
to send, that child will free itself quite quickly for accepting the next
connection, keeping the queue reasonably small.
Now, I'm not saying that the behaviour resulting from this (ie. seeing
"too busy" messages all over, half your images failing, etc.) is good
but that is another issue.