[squid-users] Squid transparent not caching apt requests from deb.debian.org

[zrm]

On 4/4/20 10:53, Alex Rousskov wrote:
> The headers you have posted tell us that the object was not in Squid
> cache when apt and wget transactions started. Since wget was started
> after apt, we can speculate that apt transaction did not cache the
> object. This is consistent with your observations. I saw nothing in the
> posted headers that would explain the difference between apt and wget
> outcomes.
> 
> Unfortunately, you did not show the headers for the case where the
> object actually got cached by Squid. You can probably do that by
> repeating the wget transaction twice. I would also repeat the apt
> transaction twice after that. It would also be interesting to see the
> wget-apt and apt-wget sequences. In summary, I would do
> wget-wget-apt-apt-wget-wget. Sleep for 10+ seconds between each
> transaction to reduce chances of overlapping cache operations.

Attached cache.log excerpt for wget-wget-apt-apt-wget-wget. It answers 
the apt requests from the cache once it's in there, it just won't cache 
it to begin with when apt makes the request:

[wget] 1586041686.600    725 192.168.111.55 TCP_MISS/200 1281195 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/199.232.66.133 application/x-debian-package
[wget] 1586041710.518    107 192.168.111.55 TCP_REFRESH_UNMODIFIED/200 
1281232 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/199.232.66.133 application/x-debian-package
[apt] 1586041733.058     69 192.168.111.55 TCP_REFRESH_UNMODIFIED/200 
1281234 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/151.101.200.204 application/x-debian-package
[apt] 1586041753.971    101 192.168.111.55 TCP_REFRESH_UNMODIFIED/200 
1281234 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/151.101.200.204 application/x-debian-package
[wget] 1586041769.162    160 192.168.111.55 TCP_REFRESH_UNMODIFIED/200 
1281232 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/199.232.66.133 application/x-debian-package
[wget] 1586041786.916     71 192.168.111.55 TCP_REFRESH_UNMODIFIED/200 
1281232 GET 
http://deb.debian.org/debian/pool/main/v/vim/vim_8.1.0875-5_amd64.deb - 
ORIGINAL_DST/151.101.250.133 application/x-debian-package

> BTW, you probably do not need to make ALL,2 logs pretty -- we can figure
> out what happens based on Squid messages if you submit one transaction
> at a time and disclose transaction sequence. You can just post (a link
> to) raw (or sanitized) logs. Compress them if they are too big.

> Before sharing the logs, please double check that the problem you want
> to address was reproduced during the test.

In this case we start with wget and then it is already in the cache for 
the requests made by apt. The problem is the data not being cached when 
apt makes the request and it isn't already there. The apt requests do 
get answered from the cache if it is already there.

The headers from the previous email show what happens when apt makes the 
request and it's not already in the cache.

>> Last-Modified: Sat, 15 Jun 2019 17:46:35 GMT
>> ETag: "1389dc-58b605823fa6e"
>> Cache-Control: public, max-age=2592000
>> Content-Length: 1280476
>> Age: 4248100
> 
> FWIW: The object is 4'248'100 seconds old. The object max-age is
> 2'592'000 seconds. Your Squid is probably using an internal max-age of
> 259'200 seconds, so Squid will require cache hit revalidation during
> subsequent transactions after Squid caches the object (if it caches it).

That makes sense. These packages never really change at all -- the 
package version is part of the URI so if it's updated the package URI 
changes rather than the data at the old URI. I might set a longer max 
age in the config once this is worked out.

> HTH,
> 
> Alex.
> 
> 

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache.log
Type: text/x-log
Size: 30262 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200404/64c9f79b/attachment-0001.bin>