Adrian Chadd wrote:
>
> On Sat, Jan 13, 2001, Robert Collins wrote:
> > Adrian,
> > does the modio code you're doing include putting the http headers into metadata, rather than just part of the data stream sent
> > to storeAppend? We must decode them something like three times during a typical MISS. (Once in http.c, once in client_side.c and
> > (i'm guessing once in store.c)
>
> The storage manager doesn't touch HTTP headers.
I have thought this over a couple of times, and I mostly second this.
Lets take the chunked encoding example. Decoding chunked to non-chunked
on the fly is not that trivial, especially considering non-order ranges
or trailers. Such decoding can be performed from a spooled reply since
then we can "know the future", but I don't see it very practical on a
live stream.
Also, I expect that in most cases where we once have been able to send
HTTP/1.1 to the client, most cache hits for that object will also be
HTTP/1.1 capable.
The major exception to the above is if the cache hit is a range request.
However, chunked encoding is used mostly for generated objects where
filesize or data is not immedately known. I expect most such objects to
not be cacheable for quite a while.
So with all this in mind, my opinion is that TE-decoding should be done
only when needed by the client. This might be a HTTP/1.0 client cache
hit, or a range request. To cover for the small "race" where a object is
stored using HTTP/1.1 and then hit many times by a HTTP/1.0 client the
object can be respooled in normalized format when decoded. Yes,
respooling is a small performance hit, but I expect the rate of those to
be quite low, making it a total gain by not having to perform the
decoding on every encoded object.
This applies to TE as well as ranges.
/Henrik
Received on Sat Jan 13 2001 - 12:54:18 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:17 MST