Hi - encouraging the correct behavior is the idea. How do I get from here to there with ATS is the problem.
Here are two sequential requests to the origin: curl -v http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt; sleep 3; curl -v http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt * Trying 192.168.5.80... * Connected to 192.168.5.80 (192.168.5.80) port 80 (#0) > GET /hs1/comprehensive.4/incremental/cksum/16824/16824090.txt HTTP/1.1 > Host: 192.168.5.80 > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Fri, 29 Mar 2019 23:02:09 GMT < Server: Apache < Last-Modified: Fri, 29 Mar 2019 18:55:49 GMT < ETag: "218e7e-6a-5854038173740" < Accept-Ranges: bytes < Content-Length: 106 < Cache-Control: max-age=604800, stale-if-error=86400 < Content-Type: text/plain; charset=ISO-8859-1 < 9826accf5f02a84ce3898777405466b5dd5069cc 2f4a9e3528e70a63c19f67963991537aac1c87b36e98fdd37496316e7a386c64 * Connection #0 to host 192.168.5.80 left intact * Trying 192.168.5.80... * Connected to 192.168.5.80 (192.168.5.80) port 80 (#0) > GET /hs1/comprehensive.4/incremental/cksum/16824/16824090.txt HTTP/1.1 > Host: 192.168.5.80 > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Fri, 29 Mar 2019 23:02:12 GMT < Server: Apache < Last-Modified: Fri, 29 Mar 2019 18:55:49 GMT < ETag: "218e7e-6a-5854038173740" < Accept-Ranges: bytes < Content-Length: 106 < Cache-Control: max-age=604800, stale-if-error=86400 < Content-Type: text/plain; charset=ISO-8859-1 < 9826accf5f02a84ce3898777405466b5dd5069cc 2f4a9e3528e70a63c19f67963991537aac1c87b36e98fdd37496316e7a386c64 * Connection #0 to host 192.168.5.80 left intact and to ATS, whose origin server is 5.80: jgarvin@opsshell901(~)$ curl -v http://muproxy009:3128/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt * About to connect() to muproxy009 port 3128 (#0) * Trying 192.168.5.199... connected * Connected to muproxy009 (192.168.5.199) port 3128 (#0) > GET /hs1/comprehensive.4/incremental/cksum/16824/16824090.txt HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/ 3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: muproxy009:3128 > Accept: */* > < HTTP/1.1 200 OK < Date: Fri, 29 Mar 2019 23:09:50 GMT < Server: ATS/7.1.4 < Last-Modified: Fri, 29 Mar 2019 18:55:49 GMT < ETag: "218e7e-6a-5854038173740" < Accept-Ranges: bytes < Content-Length: 106 < Cache-Control: max-age=604800, stale-if-error=86400 < Content-Type: text/plain; charset=ISO-8859-1 < Age: 102 < Connection: keep-alive < 9826accf5f02a84ce3898777405466b5dd5069cc 2f4a9e3528e70a63c19f67963991537aac1c87b36e98fdd37496316e7a386c64 * Connection #0 to host muproxy009 left intact * Closing connection #0 jgarvin@opsshell901(~)$ curl -v http://muproxy009:3128/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt * About to connect() to muproxy009 port 3128 (#0) * Trying 192.168.5.199... connected * Connected to muproxy009 (192.168.5.199) port 3128 (#0) > GET /hs1/comprehensive.4/incremental/cksum/16824/16824090.txt HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/ 3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: muproxy009:3128 > Accept: */* > < HTTP/1.1 200 OK < Date: Fri, 29 Mar 2019 23:11:38 GMT < Server: ATS/7.1.4 < Last-Modified: Fri, 29 Mar 2019 18:55:49 GMT < ETag: "218e7e-6a-5854038173740" < Accept-Ranges: bytes < Content-Length: 106 < Cache-Control: max-age=604800, stale-if-error=86400 < Content-Type: text/plain; charset=ISO-8859-1 < Age: 8 < Connection: keep-alive < 9826accf5f02a84ce3898777405466b5dd5069cc 2f4a9e3528e70a63c19f67963991537aac1c87b36e98fdd37496316e7a386c64 * Connection #0 to host muproxy009 left intact * Closing connection #0 And the squid ascii log: 1553901072.923 1 192.168.5.1 TCP_HIT/200 435 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - NONE/- text/plain 1553901074.984 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901079.354 0 192.168.5.1 TCP_MEM_HIT/200 435 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - NONE/- text/plain 1553901092.670 0 192.168.5.1 TCP_MEM_HIT/200 436 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - NONE/- text/plain 1553901094.088 3 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901098.777 0 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901098.801 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901106.405 1 192.168.5.1 TCP_HIT/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - NONE/- text/plain 1553901127.592 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901167.274 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901182.731 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901238.084 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901267.457 11 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901272.687 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901287.571 0 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901299.911 0 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901313.480 0 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901317.052 67 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901324.131 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901330.033 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain 1553901376.407 1 192.168.5.200 TCP_MISS/200 434 GET http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824090.txt - DIRECT/192.168.5.80 text/plain where 192.168.5.1 must be the client IP which made the request. (192.168.5.200 is the VIP fronting the cache tier). Lots of TCP_MISSes, for a file that should have a max-age of one week. This is what's puzzling me. On Fri, Mar 29, 2019 at 3:55 PM Miles Libbey <[email protected]> wrote: > Could you show 2 requests in a row to the same file? The logs you > posted were requests to different files (...241.txt, ...326.tt, > ...327.txt). > > Since your origin seems like its doing the right thing, I'd stay away > from the url_regex, and continue encouraging the correct behavior :) > > miles > > On Fri, Mar 29, 2019 at 1:28 PM John Garvin <[email protected]> wrote: > > > > Hi - > > I'm seeing consistent TCP_MISSes for URIs that happen to follow a > pattern. > > > > We distribute two kinds of .txt files. One is a serial number, say > serial.txt, with a sequential number incremented every 2-5 seconds. The > origin server, Apache http 2.2.x, has set the Cache-Control header like so: > > < Cache-Control: max-age=5, stale-if-error=86400 > > > > The second type of txt file is a checksum. There is a checksum file for > every increment of the serial number. The Cache-Control header is > > < Cache-Control: max-age=604800, stale-if-error=86400 > > > > I see consistent TCP_MISS messages in squid ascii logs for the cksum > files. > > > > 1553890048.810 1 192.168.5.200 TCP_IMS_HIT/304 189 GET > http://192.168.5.80:80/ebl/srl.txt - NONE/- - > > 1553890048.817 1 192.168.5.200 TCP_MISS/200 434 GET > http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824241.txt > - DIRECT/192.168.5.80 text/plain > > 1553890048.818 0 192.168.5.200 TCP_MISS/200 433 GET > http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824326.txt > - DIRECT/192.168.5.80 text/plain > > 1553890048.838 1 192.168.5.200 TCP_MISS/200 434 GET > http://192.168.5.80:80/hs1/comprehensive.4/incremental/cksum/16824/16824302.txt > - DIRECT/192.168.5.80 text/plain > > 1553890048.839 1 192.168.5.200 TCP_MISS/200 433 GET > http://192.168.5.80:80/hs1/sp_sender_rep.4/incremental/cksum/16824/16824327.txt > - DIRECT/192.168.5.80 text/plain > > > > First, would anyone have any insight into why ATS 7.1.4 is not caching > the cksum files (\d+\.txt) but IS caching the serial placeholders? > > The only difference I see is that the max-age value in the Cache-Control > header. > > Any pointers to look towards would be appreciated. > > > > Second, would anyone like to take a stab at a url_regex to match the > cksum paths? I have > > > > url_regex==cksum/\d+/\d+\.txt ttl-in-cache=1d > > > > but I don't see any change in the logging. > > > > Thanks for any pointers. > > > > -- > > John Garvin > > > -- John Garvin 415 816 4295
