bryancall commented on issue #12177: URL: https://github.com/apache/trafficserver/issues/12177#issuecomment-4828271204
This is expected behavior rather than a defect. On a cache miss for a potentially cacheable request, ATS speculatively acquires a cache write lock before it contacts the origin server. This happens in how_to_open_connection: when the cache action is PREPARE_TO_WRITE it issues CACHE_ISSUE_WRITE, which records the CACHE_OPEN_WRITE_BEGIN/END milestones (the CacheWriteTime you see) and attempts open_write. See https://github.com/apache/trafficserver/blob/a2c55e3db/src/proxy/http/HttpTransact.cc#L877-L895 ; the inline comment there explains the lock is taken up front to prevent multiple origin requests for the same document (collapsed forwarding / read-while-writer). The key point is that this decision is made from the request, before the origin response and its Cache-Control: private header are seen. That is why you observe a non-zero CacheWriteTime and a WL_MISS even for responses that ultimately are not stored, and why TSHttpTxnServerRespNoStoreSet (set_server_resp_no_store, a response-phase action) does not suppress it: by then the write-lock attempt has already happened. The way to avoid the speculative write lock for traffic you know is uncacheable is to disable caching early, during the read-request hook, as @shukitchan described above (for example matching the URL patterns that always return Cache-Control: private and turning caching off for them at that point). That is the only hook that runs early enough to skip the up-front write-lock attempt. Since this is a usage question that has been answered, I am closing it. Please reopen or start a discussion if you are seeing something beyond the few milliseconds of write-lock timing, such as the lock attempt actually blocking or serializing requests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
