Caching frequently requested data reduces the time that clients have to wait for responses. In addition, when frequently accessed URLs are stored in memory, the load on the origin servers is significantly reduced.
To enable caching, you must configure caching rules.
Both static and dynamically generated content from origin servers are cached.
Only complete responses (response code: 200) are cached.
Responses to only HTTP GET and HEAD requests are cached.
Oracle Traffic Director caches the response body and all of the response headers except Dest-IP, Proxy-Agent, Proxy-Connection, Server, Set-Cookie, State-Info, and Status.
Oracle Traffic Director honors Cache-Control directives from origin servers, including directives to revalidate content and to not cache certain headers.
You can configure one or more caching rules specific to each virtual server, subject to the overall limits—maximum heap space, maximum entries, and maximum object size—specified for the configuration.
You can configure the caching rules to be applicable either to all requests or to only those requests that match a specified condition.
Cached data is held in the process memory (heap), separately for each virtual server. When the instance is stopped or restarted, the cache becomes empty.
WebSocket upgrade requests are not cached.
When a client first requests an object, Oracle Traffic Director sends the request to an origin server. This request is a cache miss. If the requested object matches a caching rule, Oracle Traffic Director caches the object. For subsequent requests for the same object, Oracle Traffic Director serves the object from its cache to the client. Such requests are cache hits.
The caching behavior in Oracle Traffic Director is consistent with the specification in section 13 of RFC 2616. For more information, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html.