Search squid archive

Re: 3.5.28 partial content getting HIT but not sending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



No doubt, the connections were really being closed by the proxy itself, LIKE it was finished sending the request. It was like a loop, so it was infinite connections one right after another, but not in parallel.. the fin-packets and everything else were "in order" judgjing by their SEQ values too.

There were other refresh_patterns but none matching it. I didn't enable debug options but I can try to reproduce it.. anyway the .conf was like that for years and this was the first time a "loop" like this occurred. I upgraded from 3.5.27 to 3.5.28 but I think nothing about this was modified recently, right..?

I know most refresh_pattern options were being ignored/wrong, that's why I've disabled it altogether, and right after it, the proxy replied to the client with a TCP_REFRESH_MODIFIED instead of a TCP_HIT and the loop was gone.
The remaining options are:
refresh_pattern . 0 80% 1440
reload_into_ims off
quick_abort_min 0 KB
quick_abort_max 0 KB
quick_abort_pct 95

with no range_offset_limits

look how tiny (427 bytes) all the responses were.. and a HIT for a range request is almost a miracle here.. lol (RockStore)

1542994021.243      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.326      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.399      2 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.514      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.614      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.718      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.824      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994021.966      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994022.124      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542994036.811  14390 10.15.3.137 TCP_REFRESH_MODIFIED/206 26733678 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_DIRECT/91.189.92.150 application/x-gzip


-- 
Atenciosamente,

Heiler Bensimon Bemerguy - CINBESA
Analista de Redes, Wi-Fi,
Virtualização e Serviços Internet
(55) 91 98151-4894
Em 24/11/2018 03:33, Amos Jeffries escreveu:
On 24/11/18 6:28 am, Heiler Bemerguy wrote:
Hum, disabling that refresh_pattern and -k reconfigure seems to have
fixed it.. but.. why?

Something else is going on which is not visible in the details you have
shown.

 - is the TCP connection containing a message pipeline?
 if so the data and FIN may be related to a previous response message in
that pipeline.

 - are other refresh patterns being used (probably yes) ?
  - what are they? (before and after the change)

 - what did your cache.log have to say at the time of the connection
termination? (may need debug level 2 or 5 enabled)


Also, you were using override-* and ignore-* settings in that
refresh_pattern that are not necessary for the Debian/Ubuntu servers.

 At best they will be doing nothing to these responses (ie
ignore-no-store, ignore-private do nothing to Debian/Ubuntu responses).

 Some will be causing *worse* caching service from the proxy.
override-lastmod with your small [84 day] expiry vastly reduces the
_years_ these objects can actually be cached for, and prevents IMS
revalidation being used to determine changes properly and store
un-changed things longer. NP: Debian/Ubuntu official repositories do
fully support IMS revalidation.


Amos
_______________________________________________
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

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux