You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/05/23 16:07:44 UTC

Re: More on FreeBSD timeout problem

> [still on vacation... checking in ... lots of mail still to go]
> 
> I have an idea for an adaptive caching algorithm that would involve
> changing this sleep to a select anyhow.  Essentially I've been trying to
> figure out a way to get an adaptive cache of mmap()d files.  The best I
> can think of so far involves the parent doing cache maintenance and some
> of the children sending samples up to the parent so it can decide how to
> adapt the cache.  I need to experiment a bunch first though.

Sounds cool.

> Oh yeah and I've got another idea that'll help servers with lots of
> children -- right now it scans all children once per hit in child_main. 
> It really should only scan once per second in standalone_main and use
> SIGUSR1 to kill off one child if it determines itself to be over the
> MaxSpare setting. 

Another good idea. Vacations are good! :-)  Have fun.

> Dean





Re: More on FreeBSD timeout problem

Posted by Dean Gaudet <dg...@arctic.org>.
And one more! 

Observation:  apache uses a lot of file descriptors in many users'
configurations.  select() is linear in the value of the highest
descriptor.

Using poll() instead of select() on those architectures that support it is
a potential big sys-time win.  Apache's fd_sets are all sparse -- even
when there's lots of Listens there's also typically two log files per
vhost giving a density of 1/3rd.

Of course it all depends on the order we open our files... and we also
need to consider the select() of a single socket inside bread().  I also
think some resolver libraries use select() but haven't checked.  There's
gotta be third party libraries that use select() behind our backs too. 

So the goal would be to use a trick like my solaris > 256 fd patch to keep
log files above 256... let sockets go in below 256, and keep enough room <
32 for libraries and the per-request file descriptors.  (All those numbers
can be calculated after the config has been read of course.)  Then even if
third part libraries do select() there's a good chance they'll be doing it
on descriptors < 32 (which of course fit inside a single 32-bit int, and
means only 1 memory access for the entire fd_set ...) 

Top it off by using poll() on archs which support it and I think we've got
some sys-time savings on the configs that have lots o' vhosts.

experimentation necessary :) 

Ok laters, I'll check in next week some time.

Dean

On Fri, 23 May 1997, Randy Terbush wrote:

> > [still on vacation... checking in ... lots of mail still to go]
> > 
> > I have an idea for an adaptive caching algorithm that would involve
> > changing this sleep to a select anyhow.  Essentially I've been trying to
> > figure out a way to get an adaptive cache of mmap()d files.  The best I
> > can think of so far involves the parent doing cache maintenance and some
> > of the children sending samples up to the parent so it can decide how to
> > adapt the cache.  I need to experiment a bunch first though.
> 
> Sounds cool.
> 
> > Oh yeah and I've got another idea that'll help servers with lots of
> > children -- right now it scans all children once per hit in child_main. 
> > It really should only scan once per second in standalone_main and use
> > SIGUSR1 to kill off one child if it determines itself to be over the
> > MaxSpare setting. 
> 
> Another good idea. Vacations are good! :-)  Have fun.
> 
> > Dean
> 
> 
> 
> 
>