Re: apache style squid?

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 8 Oct 1997, Stewart Forster wrote:

> Process model -
> Thread model (with locking)
> Thread Model (without locking)
> Mixed process/thread model

I actually plan to abstract Apache 2.0 enough that we can implement all
these models and more. Not all features will work in all models... but
you should be able to get at least the features that are there now in 1.3.

I intend for each request to be handled in what essentially amounts to a
user-land thread context that is co-operatively pre-empted (all i/o points
are pre-emption points), this will be the smallest unit of execution. This
is a pretty easy model to write the protocol and handlers for -- it's
essentially the model that apache's protocol and handler code already
assumes.

These can be scheduled by kernel threads or processes. I/O will be done
asynchronously via select/poll, or via NT completion ports, or via POSIX
aio and realtime signal crud (which has the potential to be as good as NT
completion ports).

Nice dream eh?

To get the functionality of 1.3 we need almost no locking because there
are essentially no shared global data structures (unlike squid). But to
scale to the next level Apache does need shared global data ... to do
almost the same things that squid does -- caching mmap()d files is the big
one. So the API will need locking primatives. But architectures without
kernel threads will in all likelihood not have access to these
optimizations.

I've been trying to figure out a way to graft a global mmap() cache onto a
pre-forking server like Apache and I haven't been satisfied with anything
I've come up with. The best solutions I've had so far amount to a
sampling of the files in use, and using that sampling to build a mmap()
cache. i.e. of the children write() the filenames they're using on a
pipe, which a monitor process uses to tally up the busy files.

Then every 5 minutes the parent takes the list of the busiest files and
mmap()s them all into memory. It then instructs all the children to die
gracefully and replaces them as they die with new children that have an
updated mmap() cache. ("gracefully die" is a method of the child dying
off between requests so as to not interrupt requests in progress.)

Children use their cache in a read-only fashion, and just pay the expense
of mmap()ing non-cached files.

The monitor could actually be integrated with a logger, so you can get the
statistics for free. Locking only happens in the kernel... and you only
ever have a mmap cache that's up to 5 minutes stale. This could be used
for non-process models as well.

You could probably build something way more slick using inodes, but you
danger portability.

-- 
Dean Gaudet, Performance Analyst, Transmeta Corp.
--MimeMultipartBoundary--