>
> 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.
Regards,
--
Gonzalo A. Arana
