Have you tried to log the via header with option 3 turn on (proxy.config.http.insert_response_via_str)? Also, there is a cache write logging field (I have been using this lately for another project) cwr (https://docs.trafficserver.apache.org/en/8.0.x/admin-guide/logging/formatting.en.html?highlight=logging#admin-logging-fields-cache <https://docs.trafficserver.apache.org/en/8.0.x/admin-guide/logging/formatting.en.html?highlight=logging#admin-logging-fields-cache>).
If you want to get some detailed information about if a URL can be cached you can use this tool I wrote. I have used to fix out cache hit ratios (we went from 90% to close to 100%): https://github.com/apache/trafficserver/blob/master/tools/traffic_cacheable.pl <https://github.com/apache/trafficserver/blob/master/tools/traffic_cacheable.pl> Example output: [bcall@xxx ~]$ ./traffic_cacheable.pl cdn_url Total Tested: 10 Response Codes: 200: 10 (100.00%) Freshness: 0: 0 (0.00%) 1 minute: 0 (0.00%) 1 hour: 0 (0.00%) 1 day: 1 (10.00%) 1 week: 0 (0.00%) 1 month: 5 (50.00%) 1 year: 0 (0.00%) > 1 year: 1 (10.00%) undef: 3 (30.00%) Freshness with Heuristic using Last-Modified (RFC 7234 4.2.2): 0: 0 (0.00%) 1 minute: 0 (0.00%) 1 hour: 0 (0.00%) 1 day: 4 (40.00%) 1 week: 0 (0.00%) 1 month: 5 (50.00%) 1 year: 0 (0.00%) > 1 year: 1 (10.00%) undef: 0 (0.00%) Headers: Cache-Control: max-age: 9 (90.00%) undef: 1 (10.00%) Expires: undef: 10 (100.00%) Last-Modified: defined: 10 (100.00%) Pragma: undef: 10 (100.00%) Extra: Cache-Control / Expires not set: 1 (10.00%) Cache-Control / Expires / Last-Modified not set: 0 (0.00%) ATS Cache Hit: 2 (20.00%) -Bryan > On Sep 9, 2019, at 8:54 AM, Jason Yang <[email protected]> wrote: > > Hi community, > I am running an ATS cluster with debug workload (a replay of normal > workload with all headers removed) and I have noticed that a significant > portion (>20%) of cache misses are just tunneled through without being > written to disk (extracted using via header, and in my toy experiment, every > miss should be cached). I assume this happens because the aggregation write > buffer is full, so the some of the disk writes are dropped. > > I have tried to increase the the aggregation buffer from 4MB to 256MB when I > compile ATS, but it does not help. > > Besides my NVME disk throughput (> 1600MB/s for 1MB fragment 80%read+20%write > from FIO test) is way higher than what I observed during the experiments, > during which I rarely see over 200MB/s read+writing. > > Any suggestion on how I should tune ATS to gain better performance? Maybe > increase the number of cache threads per disk? Or maybe increase/reduce > fragment size? Or any suggestion on how to figure out the reason of dropped > disk writes? > Any thoughts are appreciated! > > > Best, > Jason > >
