|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 IMO better to use range_offset_limit none !dont_cache_url all to improve selectivity between non-cached and cached URL's with ACL's.... 12.05.16 23:02, Heiler Bemerguy пишет: > > > Hi Garri, > > That bug report is mine.. lol > > But I couldn't keep testing it to confirm if the problem was about ABORTING downloads or just trying to download what's already being downloaded... > > When you use quick_abort_min -1, it seems to "fix" the caching issue itself, but it won't prevent the concurrent downloads, which sucks up the link.. > > I don't know if it won't happen with aufs/ufs, I'm using only rock store..... > > > -- > Heiler Bemerguy - (91) 98151-4894 > Assessor Técnico - CINBESA (91) 3184-1751 > > Em 12/05/2016 01:01, Garri Djavadyan escreveu: >> On Wed, 2016-05-11 at 21:37 -0300, Heiler Bemerguy wrote: >>> Hey guys, >>> First take a look at the log: >>> root@proxy:/var/log/squid# tail -f access.log |grep http://download.c >>> dn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar >>> 1463011781.572 8776 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.9 >>> application/octet-stream >>> 1463011851.008 9347 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463011920.683 9645 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.9 >>> application/octet-stream >>> 1463012000.144 19154 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463012072.276 12121 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463012145.643 13358 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463012217.472 11772 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463012294.676 17148 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> 1463012370.131 15272 10.1.3.236 TCP_MISS/206 300520 GET http://downl >>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt- >>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32 >>> application/octet-stream >>> Now think: An user is just doing a segmented/ranged download, right? >>> Squid won't cache the file because it is a range-download, not a full >>> file download. >>> But I WANT squid to cache it. So I decide to use "range_offset_limit >>> -1", but then on every GET squid will re-download the file from the >>> beginning, opening LOTs of simultaneous connections and using too >>> much bandwidth, doing just the OPPOSITE it's meant to! >>> >>> Is there a smart way to allow squid to download it from the beginning >>> to the end (to actually cache it), but only on the FIRST request/get? >>> Even if it makes the user wait for the full download, or cancel it >>> temporarily, or.. whatever!! Anything!! >>> >>> Best Regards, >>> -- >>> Heiler Bemerguy - (91) 98151-4894 >>> Assessor Técnico - CINBESA (91) 3184-1751 >>> _______________________________________________ >>> squid-users mailing list >>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.squid-cache.org/listinfo/squid-users >> Hi, I believe, you describe the bug http://bugs.squid-cache.org/show_bu >> g.cgi?id=4469 >> >> I tried to reproduce the problem and have found that the problem >> appears only with rock storage configurations. Can you try with >> ufs/aufs storage? >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users > > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXNLi/AAoJENNXIZxhPexG5aAH/juZyvly/aSIguez9dAKPbbb AHpPxoky36FYOjlPbqmXjdrMPs9qNGT+Ns7WDxsNZFM0Cfbh5UgBfQc64kFoV0k/ qKseFzDLfSqbL6ppEAg3yh4/NUsBYtjT7hwBzNIUso+OM++vAQ5dJygtIWwFMRmC nSDgjTaYD/7r2JPOTEtfW8mhbC148tVaq/jAZqsefYji90vnXyLtIW5hUCcTw3nG L3PWJVhYOgSixD3K2tWu1rpgoK0F0+sqp0xqfh2Vz6BUvNIrB40k3qL7cEUnAPsH CV/O39f+yr/ggoyOmKcsVv4oQ6i2Q+eEDdy4ML7ed0mNO8nXWx1ORkgMzcxHm6Q= =NO6/ -----END PGP SIGNATURE----- |
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
