trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan M. Carroll" <>
Subject Re: Proposed partial object caching design
Date Mon, 14 Apr 2014 17:49:21 GMT
See inline.

Monday, April 14, 2014, 10:02:22 AM, you wrote:

> That looks really good, there are lots of complicated issues to get this stuff right.

Yes, but Leif will be helping so it's all good.

> Which header differences between one range fetch and the next invalidate all of the old
fragments, when should they just update the response headers.

Yes. I have a newer version of the design document which mentions that (I'll try to update
today). A key point is variation in the expiration data.

> What is the right range/partial object chunk size. (Should be configurable per-request.)

Well, per request is difficult. You would have to set it on the very first request for the
object but it would need to remain fixed for all subsequent requests per object.

> How do you handle a range request failure so client is ok with response.

There was some debate about that. How long should ATS wait if part of the client response
is already cached? I think at least until the server responds at all. If that fails, then
invalidate the object and send the fail to the client. After that, the only real failure is
for the server to disconnect and I think we might as well do the same to the client, as that
is what would happen absent ATS.

> How do you deal with a range request of indeterminate size.

That's not so bad - I thought I mentioned that in the design. Since we rewrite the first fragment
on every request that adds to the cache, we can bump up the fragment table at that point.
It's only tricky if we can't determine if the last touched fragment is really the last fragment
in the entire document.

OTOH you may mean "how do we round up a request if we don't know if the rounded up size is
too long?". I'll need to experiment with that.

> One question:
> Under this scheme can part of an object get purged?

Not currently. We can do that internally if we want to (i.e. replace existing data with fresh
data from the origin server). I suppose we could handle a range purge, although it would need
to be resized as with a GET. Would that be useful?

View raw message