On 05/12/2011 10:01 AM, sridhar basam wrote:
Thanks for the detailed explanation. How does ATS handle storage of HTTP
range replies? Is there a single copy of the object in cache or is there an
cache entry for every range request which comes in. For example
GET /foo HTTP/1.1
Range: bytes=0-2047
GET /foo HTTP/1.1
Range: bytes=1024-2047
Would these 2 requests in the order given result in the 2nd entry being
served from cache?
Neither would get cached, nor served out of cache. We only cache the
full object afaik. There is a RFE to add a "background" fetch to happen.
The problem is that for a large object, the number of possible range
objects is almost limitless (well, obviously there's a limit, but it's
huge), and it's really tricky to try to "merge" objects in the cache to
fulfill all the possible Range permutations.
So, IMO, the best solution would be for us to kick off a separate task
once we recognize a range response that is cacheable. There might need
to be a little more logic than that, e.g. keep a "frequency" table, so
that only objects with some number of requests against them kick off a
background fetch. But, this would allow for Range requests to continue
to be proxied, fast, while the background fetch fills the cache.
This would easily be done as a plugin, using the new "task" thread pool
for processing the background fill.
I am assuming if the entire object is in the cache, any subsequent range
requests would be satisfied from cache if the object is still fresh?
Correct. Once the full object is in cache, we serve the Range request as
expected. Note though that there's a performance bottleneck on large
objects, that is being worked on and will hopefully get in for v2.1.9.
-- leif
