[squid-users] Range header is a hit ratio killer

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
So,

the overall answer is "NO".

You can use Store-ID + collapsed forwarding functionality to achieve
something your want. May be together, may be separate. Hard luck :)

But this is your own problem. No one will solve the problem without the
infusion of large amounts of money to make it interesting.

:)


07.08.2016 20:12, Amos Jeffries пишет:
> On 6/08/2016 9:56 p.m., k simon wrote:
>> Hi,list,
>>   Code 206 is the most pain for our forwed proxy. Squid use
>> “range_offset_limit” to process byte-range request. when set it "none",
>> it has 2 wellknown issue:
>> 1.  boost the traffic on the server side, we observed it's amplified
>> 500% compared to clients side on our box.
>
> To which the answer currently is to see if enabling collapsed_forwarding
> works okay for your needs.
>
>> 2.  it's always failed on a lossy link, and squid refetched it again and
>> again.
>>   I've noticed that nginx have supported "byte-range cacheing" since
>> 1.9.8  by Module ngx_http_slice_module officially.
>> (1.
>>
http://nginx.org/en/docs/http/ngx_http_slice_module.html?_ga=1.140845234.106894549.1470474534
>>
>
> So? what relevance does other software features have to Squid behaviour?
>
> 
<http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F>
>
> ... to be fair the storage code in Squid is a bit hairy in places. So
> paying for it to be done is unlikely to be cheap. But still, waiting
> wont fix the problem. We nearly go there in Squid-2.7, but the
> experiment there is not able to completely port across to Squid-3 and
> had some important problems anyway.
>
>
>> 2. https://www.nginx.com/resources/admin-guide/content-caching/  ).
>>   The solution is not perfect, but it's really more usable than
>> "range_offset_limit". The secret it's use a fixed size object replaced
>> the whole file, and we can alter the request range offset and passed it
>> to server;
>
> Ah, thats what range_offset_limit does today. Updates the server request
> to say "deliver all of it" and stores the response in a file the size of
> the whole expected response the server informs will be arriving.
>
> The reason you are seeing that 500% increase in bandwidth is that
> multiple Range requests arrive while the initial part of the first
> response is still arriving back to Squid, so 5 of them get sent through
> to the server. When that first one finishes, its object becomes
> available for use as a HIT and followup Range requests get bits of it
> (so you dont see 600% -> millions of % bandwidth increase).
>
> collapsed_fowarding alters this by letting the first response be used by
> other requests while it is still incomplete. But YMMV regarding the
> savings and CF affects all traffic, so it may cause behaviours you dont
> want on other types of request. Worth a try though.
>
>
>> perhaps forward the origin range offset and cache a part of
>> the object with a range key is a better idea.
>> And squid should know how
>> to make up those object and process the request with range header.
>>   And with a fixed size object to cache it may benefits to disk IO.
>> Sounds it's similar like big-rock db concept, though I've not got
>> successed with rock on FreeBSD nor ubuntu box.
>>   Does squid has some plan to support this method or have another
solution?
>>
>
> squid is software. It doesn't have its own plans (at least I hope not).
>
> I'm not aware of any plans specifically to add Range caching any time
> soon. Ideas for how to do it get thrown around in squid-dev a couple of
> times a year, so lots of ideas but so far nothing concrete has come out
> of it. Yes rock and/or memory caches are looking like the most easily
> adapted cache types to enable storing partial objects in, someone still
> has to do the actual coding work though.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXp3yAAAoJENNXIZxhPexGDEYH/AjM5hD4ahsF9IXsMo5PrWLE
nlKCloampXBur7o1PD2uOynU35ayV2wjJlBU9P9uQrux5lus0FCHt0yD/X9rEJ4J
E1AcShLUfK6ezMdSKnn5tylfTg1+4U08/hJz3+E9PGxA//peoPVovgHu/WuFXM4X
2NtSaVeib1O7QI2Dr0yRGZKKuJ9C2/YZqTAgjUa8rT2JZAsi5bzVU4WoaXwxklZD
OolueguA63dKo3n86oAR1W0jmPoXQeHvPuleYbGLUwWVBBlRJdCHpKfVnh/D+ni4
w0hR0MRBZzS8dVNQTrTCCzuFoIH1VjHhYKKZaIQEgPpo7AsvtABNTxLM7MJmqRY=
=UX3s
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160808/9bbb2d26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160808/9bbb2d26/attachment-0001.key>