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