Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
> Mr. Llima must do something I don't, because with real world
> requests I see a 15-20 to 1 ratio of mod_proxy/mod_perl processes at
> "my" site. And that is serving <500byte stuff.
and Michael Blakeley <[EMAIL PROTECTED]> later replied:
> Solaris lets a user-level application close() a socket immediately
> and go on to do other work. The sockets layer (the TCP/IP stack) will
> continue to keep that socket open while it delivers any buffered
> sends - but the user application doesn't need to know this [...]
> Anyway, since the socket is closed from the mod_perl point of view,
> the heavyweight mod_perl process is no longer tied up. I don't know
> if this holds true for Linux as well, but if it doesn't, there's
> always the source code.
This is exactly it. I did some tests with a real-world server, and the
conclusion was that, as long as the total write() size is less than the
kernel's max write buffer, then write() followed by close() doesn't
block. That was using Linux, where the kernel buffer size can be set by
echo'ing numbers into /proc/sys/net/core/wmem_{default,max}.
However, Apache doesn't use a plain close(), but instead calls a
function called lingering_close, which tries to make sure that the other
side has received all the data. That is done by select()ing on the
socket in 2 second increments, until the other side either closes the
connection too, or times out. And *THIS* is the reason why front-end
servers are good. An apache process spends an average of 0.8 seconds
(in my measurements) per request doing lingering close. This is
consistent with Ask's ratio of 15-20 to 1 frontend to backend servers.
Now, there's no reason in principle why lingering_close() couldn't be
done in the kernel, freeing the user process from the waiting job, and
making frontend servers unnecessary. There's even an interface for it,
namely SO_LINGER, and Apache knows how to use it. But SO_LINGER is
badly specified, and known to be broken in most tcp/ip stacks, so
currently it's kind of a bad idea to use it, and we're stuck with the
two server model.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
