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 first access from a client, and delivering the requested range
from it ASAP (after receiving all the data to satisfy the first requested range) still seems to be the optimal solution
for me.
In case of Windows Updates, some unnecessary data might be cached. Same true for youtube-videos, in case of skipping
part of the video.
The amount of unnecessary cached data depends upon the client(s).
In case of just one client (or several identical ones), significant storage space will be wasted for some time, until
object is purged from cache.
But in case of many different clients (ISP, for example), wasted space will be
less, because of different needs.
It should not offset the advantage of only having one copy of data in cache.
Only disadvantage for first client could be a time delay, until requested range
is available from fetched complete object.
Caching of very large objects might change the picture.
For this, splitting the very large object in a few parts using some squid.conf-parameter like "max_cached_range_size",
together with storeID-rewrite, might be an acceptable compromise.
--
Mit freundlichen Grüßen
Reiner Karlsberg
Ringerottstr. 50
45772 Marl
Germany
Tel.: (+49) (0)2365-8568281
Mob.: (+49) (0)1788904200
-----
This eMail does not contain any virus.
Von AVG überprüft - www.avg.de
Version: 2012.0.2242 / Virendatenbank: 3184/5860 - Ausgabedatum: 26.05.2013
