ATS 9.2 showing WL_MISS on responses with Cache-Control: private

[jvgutierrez]

while debugging a spike in cache write time CacheWriteTime:%<{TS_MILESTONE_CACHE_OPEN_WRITE_END-TS_MILESTONE_CACHE_OPEN_WRITE_BEGIN}msdms> we noticed that we are getting some cache write time higher than 0 (most of them reporting a WL_MISS) even with Cache-Control: private responses from the origin server:

Date:2025-04-10 Time:18:55:39 ConnAttempts:0 ConnReuse:0 TTFetchHeaders:290 ClientTTFB:299 CacheReadTime:0 CacheWriteTime:8 TotalSMTime:299 TotalPluginTime:0 ActivePluginTime:0 TotalTime:299 OriginServer:mw-api-ext-ro.discovery.wmnet OriginServerTime:290 CacheResultCode:TCP_MISS CacheWriteResult:WL_MISS ReqMethod:GET RespStatus:200 OriginStatus:200 ReqURL:http://en.wikipedia.org/w/api.php?action=query&format=json&list=random&rnlimit=1&rnnamespace=0 ReqHeader:Host:en.wikipedia.org BerespHeader:Set-Cookie:- BerespHeader:Cache-Control:private, must-revalidate, max-age=0 BerespHeader:Connection:- RespHeader:X-Cache-Int:cp3073 miss RespHeader:Backend-Timing:D=45089 t=1744311339316247
Date:2025-04-10 Time:18:57:15 ConnAttempts:0 ConnReuse:70 TTFetchHeaders:672 ClientTTFB:682 CacheReadTime:0 CacheWriteTime:10 TotalSMTime:683 TotalPluginTime:0 ActivePluginTime:0 TotalTime:683 OriginServer:mw-web-ro.discovery.wmnet OriginServerTime:-1 CacheResultCode:TCP_IMS_MISS CacheWriteResult:- ReqMethod:GET RespStatus:304 OriginStatus:200 ReqURL:http://de.wikipedia.org/wiki/Krieg_in_Israel_und_Gaza_seit_2023 BerespHeader:Set-Cookie:- BerespHeader:Cache-Control:private, must-revalidate, max-age=0 BerespHeader:Connection:- RespHeader:X-Cache-Int:cp3073 miss RespHeader:Backend-Timing:-

A naive attempt of getting rid of those by telling ATS to not store a response ts.http.set_server_resp_no_store(1) in lua if Cache-Control: private was found didn't have any impact. The question here is why is ATS taking time (between 8 and 12ms) attempting to get a write lock for responses that are uncacheable? I'd expect to see a CacheWriteTime of 0 or -1 for every request where the origin server includes a Cache-Control: private header

related config settings:

proxy.config.cache.enable_read_while_writer: 0
proxy.config.http.cache.open_write_fail_action: 0
proxy.config.http.cache.max_open_write_retries: 1
proxy.config.cache.mutex_retry_delay: 2

[shukitchan]

I think I have similar issue. I think it may be that the write lock is needed during the request handling. So what I did is to catch a specific URL pattern that I know for sure is going to return Cache-Control: private and then turn off caching completely for those patterns during the "read request" hook.