On 2001.04.01, Daniel P. Stasinski <[EMAIL PROTECTED]> wrote:
> I'm not against compressing content, in fact it is a feature i've been
> waiting for, but when some of my static html files can be 500k or more,
> compressing them over and over seems like a waste. For completely dynamic
> content, you could then compress on the fly. Someone else descriibed a
> month or two ago that one other server keeps two versions of content, one
> plain and one normal.
This reminds me of the discussion I wanted to raise for a while now.
I'd really like to see caching implemented the way Vignette StoryServer
does it. Before people start arguing _against_ it, I just want to know
what people estimate the work effort would be.
For those who don't know, the architecture is basically:
- client requests a URL
- server looks to see if the page is cacheable
- if page is cacheable, and is cached, serve page out of cache
- if page is cacheable, and is not cached, generate the cached
page, then serve the page out of cache
- if the page is not cacheable, generate it dynamically and serve
the generated page
- if the page is static, treat the static page as though it was
actually the cached version of a dynamic page, and serve it out
of "cache"
StoryServer gives you the ability to clear pages out of cache
(effectively deleting the cache files). Otherwise, the pages stay
cached (even across restarts of the app. server).
The gimmick is that the document root of the webserver doubles as
the "cache directory" into which cached documents are stored. The
"templates" (the pages that get turned into cached documents) are
stored elsewhere. You can either manually place documents into
the cache directory and they'll get served, or if the file doesn't
exist in the cache directory, you look to see if a template exists
and then go and evaluate it, and possibly cache it.
Perhaps this kind of mechanism along with on-the-fly-compression of
content could be really neat.
Perhaps you have a large chunk of content and compression would be
really advantageous. Perhaps the content only changes on an hourly
basis. Perhaps you could create a template which pulls the content
from wherever it lives. Perhaps, when a user requests the template,
it gets cached. Perhaps, if a user requests a compressed version,
the _compressed version_ gets cached.
Once an hour, schedule a clear-cache of both the cached page and
the compressed version of the cached page. The very next request
for each type (compressed or non-) will force the content to be
generated (and possibly compressed) and saved to cache. All other
requests until the next clear-cache don't incur the overhead of
on-the-fly compression -- they just serve the page out of cache
just like any other static content.
IMHO, this is one of the big reasons why StoryServer actually wins
in the web app. arena over AOLserver "out of the box" -- it's
easy to make large pseudo-dynamic sites really scream, because
of this very, very simple caching mechanism. I know there's lots
of ways of implementing _some sort_ of caching with AOLserver
(ns_cache, nsv, etc.) but none this "simple" or "transparent" ...
and I think it could be really useful.
Anyone have any thoughts? Am I alone on this one?
- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
