httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: [PATCH] lingering_close performance improvement
Date Wed, 12 Feb 1997 02:40:13 GMT
On Tue, 11 Feb 1997, Jim Jagielski wrote:

> Chuck Murcko wrote:
> > 
> > Roy T. Fielding wrote:
> > > 
> > > >I will not object to your committing it, but ask that everyone keep in
> > > >mind that this may not be what we end up shipping in 1.2 if something
> > > >better comes up.
> > > 
> > > Yes, absolutely -- I just want the testing to be based on what we have now
> > > instead of what we had last week.
> > > 
> > > >What do you think of Dean's suggestion of keeping a history of sockets
> > > >that are lingering and then just going through them each time through the
> > > >main loop before we accept a new request?  Assuming, of course, that it
> > > >can be implemented cleanly which is not necessarily a valid assumption.
> > > 
> > > That is basically what RST's multithreaded code does, and I think it is
> > > a much better idea than what we are currently doing.  I just don't know
> > > how to do it without introducing multithreading, etc.
> > > 
> > True, but this is really the only correct (and nonkludgey) way to deal
> > with pipelined request errors, isn't it? We'll need this anyway, since I
> > don't think Henrik's tests ran on really crappy connections.
> > 
> 
> Unless we are fully multithreaded, doing this really puts a hurting
> on those systems with limited numbers of fd's :/

Passing fds back and forth between processes could, but with Dean's
suggestion of doing it all in the child you only have a minimal increase; 
they can still be thrown away almost (the resolution for how often we can
check in the child may not be frequent enough; one of the things I have to
look at later this week when I give it a try) as quickly, so you just have
less children holding close to the same number of fds. 



Mime
View raw message