[squid-users] Getting the full file content on a range request, but not on EVERY get ...

[Amos Jeffries]

On 14/05/2016 12:38 a.m., Garri Djavadyan wrote:
> On Fri, 2016-05-13 at 08:36 +1200, Amos Jeffries wrote:
>> Have you given collapsed_forwarding a try? Its supposed to prevent
>> all
>> the duplicate requests making all those extra upstream connections
>> unti
>> at least the first one has finished getting the object.
> 
> Amos, I believe that the above quote describes default Squid's action,
> which does not require collapsed_forwarding. The details of my
> experiments can be found here http://bugs.squid-cache.org/show_bug.cgi?
> id=4511#c0. Thanks.
> 

The default action should be to fetch each range request separately and
in parallel. Not caching the results.

When admin has set only the range offset & quick-abort to force full
object retrieval the behaviour Heiler mentions happens - lots of
upstream bandwidth used for N copies.
 The first one to complete starts to be used as a HIT for future
reuqests. But as each of the initial transfers completes it replaces the
previously cached object as the one being hit on.

So timing is critical, if Squid happens to delay any of the parallel
requests just long enough in its TCP accept() queue, auth or ACL
processing they could become HITs on an already finished object.

Amos