RE: Storing partial responses

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: Wednesday, 13 December 2000 3:22 PM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: Storing partial responses
>
>
> On Wed, 13 Dec 2000, Robert Collins wrote:
>
> > What about a mixed approach?
>
> > - meta level support for the global cases, the logic on caching,
> > deciding what's needed upstream, and what downstream format to
> > send the response in (specifically a Content-Range or
> > multipart/byteranges).
>
> > - register callbacks into the FS to perform FS routines such as
> > storing the actual partial ranges. Then the FS can daisy chain
> > them, use sparse files, whatever takes the FS implementors fancy.
>
>
> Looks like I need to improve my classification:
>
> (0) FSs assume that an object key corresponds to a single,
> complete response (object). A FS is a database of
> blobs, known to be complete objects, with a
> store(key, object)
> object = load(key)
> interface. This is the current approach. It makes
> impossible to support partial objects.
>
> (1) FSs know absolutely nothing about partial objects
> (or complete objects for that matter). A FS is a
> database of blobs with unique keys, with a
> store(key, blob)
> blob = load(key)
> interface. FS optimizations are limited because the
> semantics of a key is not known (its just a unique opaque
> string). Meta-level code assembles blobs into complete
> or partial objects.
>
> (2) FSs know what a "part of an object" is. A FS is a database
> of partial and complete objects with a
> store(key, part_description, part)
> part = load(key, part_description)
> interface (where a part can be an entire object, of course)
>
> (2a) Optional support: FSs can refuse to store partial
> objects, leaving it to meta level to handle the
> "refused-to-cache" request/response appropriately.
> This approach gives shortest time-to-stable, but
> will likely to leave some FSs behind for a long time.
> It also makes introduction of new FSs easier.
>
> (2b) All FSs must implement the above methods. This approach
> is fair but slow, compared to (2a).
>
> In either case, a meta level that knows how to handle partial objects
> will be required. For example, HTTP "ranges" logic will reside on that
> level.
>
> Alex.
>
>

Hmm. Well I am definately heading to a (2) approach, because performance
tuning will need both FS and meta level activities.
That was what I was meaning by meta level support and callbacks in to
the FS.
(2a) optional support: I think this is the way to go. Not for time to
stabile so much, but because it's 'free'. It's free because if the FS
won't store partial objects, then the meta level code can simply always
consider the store to have a MISS on that key.

when you say fair but slow I presume you mean development time not
performance?

Rob
Received on Tue Dec 12 2000 - 22:00:51 MST