httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Core server caching
Date Wed, 23 Sep 1998 21:01:19 GMT

The core problem of caching seems to me to get confused by the
complexity of designing a caching proxy.  If one ignores that then the
core problem of caching seems quite simple.

Let's say the core server has a cache consisting of a set of fragments
that it can return as all or part of a response quickly.  The only
operations on these entries might be create, delete, and send.  It
might just barely be useful to have a rank attribute on these entries
so the core had a hint which entries were believed hotter than others.

Then the non-core parts of these server would mark off parts of their
output as "cachable" when streaming out a response.

  cache_id <- new_cache_id();
  begin_cachable_content(id),
  ...other chunks...
  end_cachable_content(id)

either when generating a response or just when loading the cache.

Later they can stream out quickly by doing resend_cached_chunk(id).

It isn't the core server's job to implement some wonderful cache
management algorithm that fits all sizes of users.  That's a
problem that ought to be left to the non-core parts of the site.
If they want to invalidate the cache at press time, request time,
restart, well that's up to them.

It is the core server's job to implement the mapping from URL to
response generator in a sufficiently quick and flexible way.  I don't
see that the selection of a generator which uses the cache is a
special case of that part of the design problem.

Note if the API the core has to caching is very small then it becomes
a lot easier to implement variations of it behind the scenes.

  - ben hyde

Mime
View raw message