httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] lingering_close performance improvement
Date Mon, 10 Feb 1997 20:41:24 GMT
I'll test your patch on HotWired later this week.

Dean

On Mon, 10 Feb 1997, Roy T. Fielding wrote:

> >No, it DID go away in many cases.  I have a dozen reports of NO_LINGCLOSE
> >eliminating the problem.  The keepalive bit does not explain the
> >difference between 1.1 and 1.2 nor does it explain why people still had
> >problems when they disabled keepalives.  There is another problem.
> 
> All of those reports are pre-1.2b6.  The only problems that we know
> about now, that we have any reports about, should be fixed by the patch
> I made.  On my Ultra1, 1.2b7-dev + my patch is now considerably
> faster than 1.1.3, but the only way we can really test it is if
> we place it on one of the high-load servers.
> 
> At the very least, I'd like to commit it so that others can test
> (and so that I can commit other things in http_main.c, like the
> SIGHUP patch).
> 
> >> The only concern we have with l_c() right now is the length of the
> >> timeout and the fact that it might block in a read(), both of which
> >> are fixed in my patch which people have failed to vote on.
> >
> >Personally, I'm not sure if 1s is long enough.  If the RTT is greater than
> >1s (and it often is for dialin users downloading multiple pages) then the
> >same problem would seem to be possible.  
> 
> Possible, yes, but we can take care of 99% of the potential problems
> by just concerning ourselves with clients that are sending a stream
> of data, and for them 1s is long enough.  We already handle the PUT/POST
> drain in mod_cgi, so this code just handles pipeliners and pre-input
> error conditions.  Given the concern people have for leaving client
> processes around, I don't think we can do any better without SO_LINGER.
> 
> ....Roy
> 


Mime
View raw message