Chuck Murcko wrote:
> This is interesting: what happens if you replace the browser
> in your diagrams with another Apache + cache? It seems like a
> reasonable way to do cache synchronization amongst a server
> cluster, or an akamai-type distributed cache. The caches could
> transfer compressed objects between themselves, so compression
> would happen only once per object no matter how many caches are maintaining
> sync.
This is what squid does - yes - this would be a very useful feature
indeed.
Some would argue that putting a squid cache in front of Apache will
solve this problem, BUT - the idea falls down due to request logging.
The only sane place to collect hits statistics is at the topmost level
in the cache hierarchy. If you were using squid, then squid would have
been doing all the logging, and handling different virtual hosts in
different files isn't something squid is any good at. So - a 100% Apache
solution would be great.
Squid already uses a number of protocols to implement parent and sibling
caches - Apache's new "any protocol" support should be ideal for this.
One thing I wouldn't do is build the capability into mod_cache - I'd
build the capability directly into mod_proxy itself, with the ability to
query the objects in the storage manager directly. This way mod_cache
doesn't get the ability to talk to other servers out there - that's
mod_proxy's job.
In fact this might be a good reason to spilt out the storage manager
into it's own module: mod_storage. This module could be used to load and
save any object to any kind of storage, be it RAM, disk, database, LDAP,
whatever.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
