Logging Cache Results¶
In addition to recording information about client and origin requests and responses, Traffic Server exposes detailed information about cache interactions for every request which passes through a node. This information is incredibly important to establishing an efficient caching configuration, though it is only present in your logging output if the crc logging field is used. For even more detail, see crsc.
Interpreting Cache Results¶
An immediate benefit to including cache result codes in your logging output is the ability to trace and diagnose specific problems. You may be able to tell without any help that a particular request takes much longer than it should, and HTTP response inspection reveals a very small (or possibly zero) value for the Age header, but you may still be left wondering why. If it’s possible to correlate the problematic request(s) with access log entries, the cache result code may help shed significant light.
Misconfigured headers from your origin may be resulting in clients aggressively
sending no-cache requests, or cache objects may be going stale too rapidly
and IMS (If-Modified-Since) requests are reaching back to the origin server
more often than you anticipated. Perhaps this isn’t a regular web browser
request, but part of an application’s API and the HTTP method being used isn’t
understood by Traffic Server and instead just gets passed blindly through to the origin.
These and other situations can all be revealed pretty quickly by logging and
inspecting Traffic Server cache results.
Even more useful as an overall monitoring and optimization strategy is to log the cache results, and then produce reports through log aggregation and analysis tools. Such an approach can reveal larger trends and unearth problems or inefficiencies that don’t necessarily result in outright client errors or bug reports from users.
A high ratio of TCP_MISS to TCP_HIT events can indicate that your cache is sized too small and objects are being evicted too quickly for your Traffic Server cache to reduce traffic to your origin servers - largely defeating the purpose of having a caching layer at all. Here too small could be anything from simply not sized appropriately despite your hopes and intentions otherwise (hopefully because you’re still fine-tuning your configuration based on monitoring and reporting results) to the difficult situation in which you operate very large sets of cacheable data that see too sparse access patterns to easily create a single cache policy.
In the latter scenario, you may need to investigate tiered caching policies on subsets of your data to better tune the eviction rates, or partition data across different storage volumes to keep less-frequently, but very large objects (e.g. hours-long, archived training videos from years past) from suddenly evicting large numbers of more moderately visited, much smaller, but infrequently-changing objects (e.g. costly HTML pages of your semester course schedules generated by an unruly SQL query in your aging CMS).
Large numbers of TCP_CLIENT_REFRESH events for objects which are supposed to be
served primarily (or perhaps almost exclusively) from your Traffic Server cache may
indicate that something, possibly a misconfiguration of the caching headers in
your origin server responses, is triggering clients to submit requests with
no-cache enabled.
Almost any non-trivial occurrence of TCP_REF_FAIL_HIT requests is a signal that your origin servers are not responding to proxied requests from Traffic Server when they should. Traffic Server has found an object in its cache, but determining it to be stale attempted to refresh the object from an origin and was met with failure. The client still received an object back, but there was a chance it may have been outdated as a result of the origin failure.
Cache Result Codes¶
The following are all possible cache result codes you will currently encounter in Traffic Server logging output, and what each one means.
TCP_HIT¶
A valid copy of the requested object was in the cache and Traffic Server sent the object to the client.
TCP_CF_HIT¶
A valid copy of the requested object is being updated in the cache and Traffic Server sent the object to the client.
TCP_MISS¶
The requested object was not in cache, so Traffic Server retrieved the object from the origin server (or a parent proxy) and sent it to the client.
TCP_REFRESH_HIT¶
The object was in the cache, but it was stale. Traffic Server made an
if-modified-since request to the origin server and the
origin server sent a 304 not-modified response. Traffic
Server sent the cached object to the client.
TCP_REF_FAIL_HIT¶
The object was in the cache but was stale. Traffic Server made an
if-modified-since request to the origin server but the server
did not respond. Traffic Server sent the cached object to the
client.
TCP_REFRESH_MISS¶
The object was in the cache but was stale. Traffic Server made an
if-modified-since request to the origin server and the server
returned a new object. Traffic Server served the new object to the
client.
TCP_CLIENT_REFRESH¶
The client issued a request with a no-cache header. Traffic
Server obtained the requested object from the origin server and sent
a copy to the client. Traffic Server deleted the previous copy of
the object from cache.
TCP_IMS_HIT¶
The client issued an if-modified-since request and the object
was in cache and fresher than the IMS date, or an
if-modified-since request to the origin server revealed the
cached object was fresh. Traffic Server served the cached object to
the client.
TCP_IMS_MISS¶
The client issued an
if-modified-since request and the object was either not in
cache or was stale in cache. Traffic Server sent an
if-modified-since request to the origin server and received the
new object. Traffic Server sent the updated object to the client.
TCP_SWAPFAIL¶
The object was in the cache but could not be accessed. The client did not receive the object.
ERR_CLIENT_ABORT¶
The client disconnected before the complete object was sent.
ERR_CLIENT_READ_ERROR¶
The client had read errors (network problems).
ERR_CONNECT_FAIL¶
Traffic Server could not reach the origin server.
ERR_DNS_FAIL¶
The Domain Name Server (DNS) could not resolve the origin server name, or no DNS could be reached.
ERR_INVALID_REQ¶
The client HTTP request was invalid. (Traffic Server forwards requests with unknown methods to the origin server.)
ERR_READ_TIMEOUT¶
The origin server did not respond to Traffic Server’s request within the timeout interval.
ERR_PROXY_DENIED¶
Client service was denied.
ERR_UNKNOWN¶
The client connected, but subsequently disconnected without sending a request.
Cache Result Sub-Codes¶
The following are all possible cache result sub-codes you will currently encounter in Traffic Server logging output, and what each one means. These sub-codes can offer more specific details that are not exposed in cache result codes.
NUM_REDIRECTIONS_EXCEEDED¶
The origin server responded with a redirect, but following this redirect would
exceed the configured maximum number of redirects allowed:
proxy.config.http.number_of_redirections