Hi,
just a basic question, relevant to squid2.7, at least:
AFAIK, without looking into the src code, squid2.7 requests and caches
the complete object, before delivering the data to fulfill the first
range request.
Delivery might even start as soon as the data for the actual range
request is
On 28/05/2013 9:14 p.m., Reiner Karlsberg wrote:
Hi,
just a basic question, relevant to squid2.7, at least:
AFAIK, without looking into the src code, squid2.7 requests and caches
the complete object, before delivering the data to fulfill the first
range request.
Delivery might even start as
On 05/28/2013 03:14 AM, Reiner Karlsberg wrote:
As far as I know squid serves 206 partial responses from cache only if
the full object exists in cache.
I can not follow the flow of execution in squid2.7, but I am not shure,
that you are correct.
These excerpts from squi2.7 MIGHT indicate,
25.05.2013 03:17, Eliezer Croitoru:
The idea is to proof that caching partial content as a stand alone
object in squid is better then trying to cache the full object each time
it's being requested.
For Windows Update one service pack can be like 750 Mb. but this is
sparse uncompressed file,
Exactly the same with WU. Whenever you need a big chunk of the file BITS will
start requesting data in pieces depending
on the latency: the faster the bigger.
This is the same behaviour, as I have seen for videos from youtube.com.
So, as a general solution, caching the complete object on
Since the development of StoreID there were some advances in couple
areas and it seems like the idea of 206 responses caching can be moved
on to the next level.
Based on my work with GrreasySpoon for youtube (mentiond here:
