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_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