httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: Apache 2.0/NSPR
Date Fri, 11 Sep 1998 16:56:27 GMT
Dean Gaudet wrote:
> On Thu, 10 Sep 1998, Simon Spero wrote:
> > 2) Layering is dangerous to performance, and should be collapsed as much
> > as possible. This is part of the job of the middle end.
> This was part of why I was prompted to say we should look at zero-copy,
> "page based" i/o... in particular, the chunking layer doesn't need to
> modify anything.  It just needs to build iovecs.  But without reference
> counting on the buffers we have to actually copy the contents rather than
> just pass them around...

Do we really need reference counting? Can't they have a common
allocation/deallocation method, and get ownership handed through the
layers - last one out turns off the lights (err, lowest layer releases
the buffer).

> > 4) A lot of the cache could be made kernel resident. This means that
> > although cache invalidation can be complicated (objects can have a
> > validate method), simple tests should be handlable simply and predictably-
> > for example file modification date, eq checks for negotiation etc.
> > Otherwise you have to leave the kernel to validate.
> For some sites it'd be sufficient to invalidate the entire cache on a
> regular basis.  That's pretty easy to do.  But yeah invalidation is in
> general a painful problem...
> > 5) The cache allows more objects than normal to be treated as files (i.e.
> > they have finite length, rather than being data streams). This makes it a
> > lot easier to attach file system protocol front ends to the middle-end
> > namespace (in particular code from Samba and the old user mode NFS
> > server). This allows the server to mediate *all* access to the data store,
> > making it easy to use *active* invalidation, with no validation checks at
> > all in the fast path.
> Hmmm... interesting.
> On a related note, we need to abstract those bits of the filesystem which
> we need to serve HTTP so that backing store doesn't have to be a
> filesystem.  I'd say this should even go as far as modules being able to
> open() a URI and read from it -- so that it can be as transparent as
> possible.  So rather than use ap_bopenf() directly (the apache-nspr
> equivalent of fopen()), modules open a URI through some other interface,
> and that may go to the filesystem or go to a database/whatever.
> A difficulty in this is access control -- there's a difference between an
> external request requesting some files, and an internal module requesting
> them.  Different rights.

Are you saying that all interlayer comms should be in terms of URIs? And
qualifying headers? (I'm thinking this integrated neatly with Magic

> > 6) This implies that the namespace model should be mappable in terms of
> > directories, files, and specials (cgi-scripts, etc). This gives the
> > hierarchical component of the resolution process a higher priority than
> > the other phases.
> I'd like to see the namespace have "mount points" somewhat like the unix
> filesystem.  This controls the hierarchy as far as what the underlying
> store is... and it's a simple system, easy to optimize for.  i.e. I'd
> really like to avoid "if the URI matches this regex then it's served by
> database foobar".  That's far too general.

Sounds like a plan.



Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|
and Technical Director|Email: |
A.L. Digital Ltd,     |Apache-SSL author
London, England.      |"Apache: TDG"


View raw message