httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonzalo Arana" <>
Subject Re: Generic cache architecture
Date Wed, 03 May 2006 21:05:28 GMT
> >
> > Let's talk about httpd.  We have a cache of ssl sessions.  We have
> > a cache
> > of httpd response bodies.  We have a cache of ldap credentials.  A
> > really
> > thorough mod_usertrack would have a cache of user sessions.
> >
> > So really, it doesn't make sense to have these four wheels spinning
> > out of
> > sync at different stages of stability and performance.  I'm
> > strongly +1 to
> > provide this functionality once, and reuse.
> On the contrary, it makes no sense whatsoever to use a generic
> storage facility for cached HTTP responses in a front-end cache
> because those responses can only be delivered at maximum speed
> through a single system call IFF they are not generic.  That is
> why our front-end cache is not, and has never needed to be, a
> generic cache.

I have to disagree: indeed a single syscall implies maximum speed &
minimum memcpy (kernel to user, user to kernel), but consider that a
cached response perhaps needs to get compressed (Transfer-Encoding:
gzip, for instance).  So, there is no way to assure that a single
syscall will work.

A generic cache, if designed with propper care, could provide a
filedescriptor, which can be used with sendfile(2) or
mmap(2)/write(2)/munmap(2) or any other combination.

> A front-end cache is a completely different beast from a
> back-end cache.  It doesn't make any sense to me to try to

what do you mean by 'front end cache' and 'backend cache'?

> make them the same, and it certainly isn't elegant.  SSL
> session, ldap credentials, sessions, and all those related
> things are trivial memory blocks that *are* suitable for
> back-end caching.

> I have no objection to creating a module for back-end caching.
> I have no objection to creating five different forms of caching
> modules, each with its own qualities, that can be selected by
> configuration (preferably based on some suggested site profile).

perhaps each kind of cache could be used by different parts (SSL
session, ldap credentials, session, would use the 'backend cache'),
and HTTP would use 'front-end cache'.

> However, I see no reason to start by changing the existing
> module names and assuming that one cache fits all.


Gonzalo A. Arana

View raw message