[squid-users] Vary object loop returns

[Yuri Voinov]

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


07.06.2016 4:57, Amos Jeffries пишет:
> On 7/06/2016 5:55 a.m., Yuri Voinov wrote:
>>
>> So.
>>
>> Squid DOES NOT and DON'T BE support gzip. The only way to do it - use
>> ecap + desupported ecap gzip adapter. Let's accept this. We can support
>> gzip. With restrictions. Ok.
>>
>> any other compression - false. No. No way. Get out. and so on.
>>
>>  identity - this is uncompressed type.
>>
>> That's all, folks.
>>
>> Finally. As Joe does, we can remain only gzip and identity in
>> Accept-Encoding and truncate all remaining.
>
> Locking the entire Internet to using your personal choice of gzip
> compression or none.
>
> gzip is the slowest and more resource hungry type of compression there
> is. deflate is actually faster for clients and just as widely supported.
Unfortunately, Amos, no one has written any other compression algorithms
support module. We have to eat what they give.
>
>
>>
>> Without any problem. Moreover, this type of can be push to all brunches
>> of squid without any problem, because of this dramatically increases
>> byte HIT.
>
> Responding with a single object to all requests makes your HIT ratio
> 100% guaranteed. The clients wont like you though if all they ever see
> is the same cat picture.
>
> It sounds ridiculous when put that way, but that is what these patches
> are doing for a unknown number of those "gained" HITs. See my previous
> post about how none of these patches are changing the request the server
> gets.
But no one asked the question - why Squid in production installations
has such a low hit ratio that raises the question of expediency of
application caching proxy. We do believe that this is a caching proxy?
>
>
> You are once again sweeping asside the critical requirement of content
> integrity to achieve high HIT ratio. Which is not something that I can
> accept into Squid as a default action.
I continue to believe that 20% is unacceptably low cache hit ratio,
given the very aggressive settings and the active use of Store ID. Which
brings us back to the idea of the feasibility of using the SQUID as a whole.
>
>
> 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
 
iQEcBAEBCAAGBQJXVopgAAoJENNXIZxhPexGTJYH/iYl6gaWEYqnqgAB7vPytR6D
m2zKnUgL9Rit+LWCmvO4rA6/f2tXEGYvNJDk87gzmYDsS0yuPBySM4OHhZW3JKTK
Ly1DfnPBownfnw38zprWL70iz8UZ4nrXJZTOuxqe5gJC77aU9X+iuqARXk5naYUh
D0LaOnDgTNy1omVOMfeDs2pQwQyRzweAlFzZ30Xktt8DFA9wWv/tRQitLB2ubdsh
tw34Z1sjLYAW7M4EkmHcdkqSf2gKYeAylqst/3pFYAJJq1EUXsqF/J88JcSDjLl9
Bqq+29AvxNlg2EiNayC1PJ8FET0R/X8bjw1+mnvhCDWLKlSnKE/wmlqU4swaEsk=
=UR/N
-----END PGP SIGNATURE-----

-------------- 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/20160607/0031775b/attachment.key>