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 <peter.waynechina@gmail.com> 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
>
>
|