httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: roy's l_c perf patch and spareservers
Date Sat, 15 Feb 1997 21:59:17 GMT
On Sat, 15 Feb 1997, Roy T. Fielding wrote:

> >Hang on.  Dean is having trouble with the FIN_WAIT_2s, not any of the
> >other performance issues because the FIN_WAIT_2s hurt his servers too much
> >to keep lingering_close running long enough to get a good idea.  This is
> >unrelated to speeding up the code, but is about the problem that has been
> >happening all along of connections hung in FIN_WAIT_2.  It is not fixed in
> >b6.  Connections still hang in FIN_WAIT_2.
> I didn't say anything about speeding up the code.  There exists a tree
> of possibilities regarding the source of FIN_WAIT_2 states, and Dean
> just lopped-off one of the branches.  If he is seeing more FIN_WAIT_2
> states with the new lingering_close than with NO_LINGCLOSE, then the
> source of those FIN_WAIT_2 states is not keepalive-enabled browsers.
> Moreover, it means that either there is another bug in lingering_close,
> or IRIX is treating shutdown/read/close differently than just close.
> We should be able to reduce the possibilities further by seeing if it
> is stuck inside the TCP stack, in the call to shutdown, or in the
> read loop.  If it is the last case, we have a bug.  If it is either of
> the first two cases, then we will know that it is impossible to perform
> any kind of lingering on IRIX and we can default to NO_LINGCLOSE
> for that platform in conf.h.

I am almost certain that there is blocking anywhere in lingering_close
which is causing the problem with FIN_WAIT_2s.  Performance slowdowns,
sure, but not FIN_WAIT_2s; they are almost completely seperate problems. 
The difference sequence of events when using lingering_close causes a
different interaction in the TCP stack then when we just do a close which
leads to connections hung in FIN_WAIT_2.  This is the problem that has
been happening all along.  We (well, me anyway and I have said it numerous
times) have known for a month that the problem is NOT just with keepalives
and has NOT yet been found and _is_ directly tied to lingering_close. 
That is what I have been trying to track down for the last month.  It is
premature to dismiss it as being impossible to do any sort of lingering
close because the current one doesn't work if we don't know why it doesn't

I have some ideas, but can not replicate the problem so they are all just
wild guesses.

View raw message