httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: Apache 2.0/NSPR
Date Wed, 09 Sep 1998 23:33:49 GMT
On Thu, 10 Sep 1998, Ben Laurie wrote:

> Like I said, Dean mumbled something about flushes. Natch, if you have
> threads, the approach is different to if you don't. I suppose the Big
> Question is whether we are interested in implementing layered I/O for
> non-threaded environments.
> BTW, Alexei said some stuff about caching in between layers, which I
> seem to have mislaid. Let me take this opportunity to say that sounds
> cool and he should pursue it! I have some stuff to say about databases,
> but I'll wait until I've drunk less.

How can you drink less? That's like saying "I'll wait until I'm less old." 
You already drank it. Too late now. Unless you drink enough to overflow
the drink counter and it goes back to zero.  You might try that.

Anyway, the 'layers' I was talking about do not have a one-to-one
correspondence to the layers of an I/O stack. I was talking about the
layering of modules to create a response. Which would be implemented, of
course, using one or more I/O layers for each module. So yeah, that's
basically correct.

I think that would work something like this: Let's say a response starts
with the result of database access, which is then parsed through PHP, and
then sent.  So the response looks something like this. This layering is
constructed by the "middle end" of the server based on the URL, server
config, whatever: 

database -> PHP -> client

Each of those involve one (or more) NSPR layers. But we insert a cache
layer between each module: 

database -> cache-write -> PHP -> cache-write -> client

The cache layer is write-through and just records, if appropriate, the
output from each module, along with meta-data it gets (from some other
method) about what each module layer does to the parameters of the
response (e.g., what it negotiates on). It uses that data to decides if
that layer is worth caching. If not, it just passes on the data. Either
way, it's transparent; it doesn't affect this response at all.

Anyway, next time a request comes in, the middle end consults the cache,
and figures out how much of that request is cached. It might discover that
the database access is valid for the new request, but the PHP layer
depended on User-Agent, which is different. So it constructs the new
response like this:

cache-read -> PHP -> cache-write -> client

Or maybe it's the same request with the same User-Agent, and it can pull
the whole thing out of the cache:

cache-read -> client

(this last one can be done in the kernel, or in an otherwise streamlined
manner. Much speedup. And the neat thing is that neither the database nor
mod_php have to know *anything* about it, as long as they properly report
their metadata. We'll need to make that sure that's easy for module
authors to have their modules do.)

Basically, that's how I think it should work. It's basically what we
talked about in SF (sorry you weren't there Ben, you probably would have
enjoyed it). Doesn't sound too hard to implement either, once we get the
cache and middle end parts working perfectly (hah!).

-- Alexei Kosut <> <>
   Stanford University, Class of 2001 * Apache <> *

View raw message