Why does store.log show RELEASEs for cache hits?
there are plenty of RELEASE entries in the store log with filenumber FFFFFFFF that correspond to access.log entries with hits (e.g. TCP_HIT/200). Since they were found in the cache, they must have been cachable. How is it that these unchachable responses are served as hits? The store.log entries that you refer to are most likely cache validation responses. Squid sends an If-Modifided-Since (or other validation) request to the origin server. If the response comes back as 304, then the client receives the original cached response from Squid. When analyzing store.log, be sure to consider the status code field (6th). You may want to ignore all log entries where the status code is not 200 (Ok).
there are plenty of RELEASE entries in the store log with filenumber FFFFFFFF that correspond to access.log entries with hits (e.g. TCP_HIT/200). Since they were found in the cache, they must have been cachable. How is it that these unchachable responses are served as hits? The store.log entries that you refer to are most likely cache validation responses. Squid sends an If-Modifided-Since (or other validation) request to the origin server. If the response comes back as 304, then the client receives the original cached response from Squid. When analyzing store.log, be sure to consider the status code field (6th). You may want to ignore all log entries where the status code is not 200 (Ok).
