Avi Load Balancer caches HTTP content, thereby enabling faster page load times for clients and reduced workloads for both servers and Avi Load Balancer.
When a server sends a response (for example, logo.png), Avi Load Balancer adds the object to its HTTP cache and serves the cached object to subsequent clients that request the same object. Caching thus reduces the number of connections and requests sent to the server.
Enabling caching and compression allows Avi Load Balancer to compress text-based objects and store both the compressed and original uncompressed versions in the cache. Subsequent requests from clients that support compression will be served from the cache. Avi Load Balancer does not need to compress every object every time, greatly reducing the compression workload.
Responses Eligible for Caching
When caching is enabled, Avi Load Balancer caches HTTP objects for the following types of responses:
HTTP/HTTPS
GET, HEAD methods
200 status code
Avi Load Balancer also supports caching objects from servers in HTTPS pools.
HTTP/2 responses from the server are cached.
HTTP Caching feature is not supported for pool groups on Avi Load Balancer.
Responses Not Cached
Avi Load Balancer does not cache HTTP objects for the following types of responses:
Put / Post / Delete methods
Request Headers:
Cache-Control: no-store
Authorization
Response Headers:
Cache-Control: no-cache
Expires header’s date is already expired
Warning, Set-Cookie, Vary: *
Cache-Control: private, no-store
Both etag and Last-Modified headers do not exist and either:
GET/HEAD method includes a Query
No expires/max-age header exists
Non-200 status codes
It is possible for caching to not work with policies or DataScripts present on the virtual service. Consider disabling caching in the application profile if policies and DataScripts need to be applied to the virtual service.
Verify Object Served from Cache
To validate that an object is successfully served from the cache, navigate to the logs page of a virtual service. Apply the filter - cache_hit= ”true”. This filters all requests that were successfully served from the cache. When using logs, ensure that you enable Non-Significant Logs to show non-error traffic, and ensure the logging engine is capturing the Non-Significant logs for the time of the test. For more information, see Virtual Service Application Logs in the VMware Avi Load Balancer Monitoring and Operability Guide.
For more information, see Shared Memory Caching.
Cache Configuration Options
HTTP caching is enabled within the Application Profile of Type HTTP.
Navigate to Select Type as HTTP.
Within the HTTP profile, navigate to the Caching tab and enable caching by selecting the Enable Caching check box.
Configure the following parameters as required:
X-Cache - Avi Load Balancer adds an HTTP header labeled X-Cache for any response sent to the client that was served from the cache. This header is informational in nature, and indicates that the object was served from an intermediary cache.
Age Header - Avi Load Balancer adds a header to the content served from cache that indicates to the client the number of seconds that the object has been in an intermediate cache. For example, if the originating server declared that the object must expire after 10 minutes and it has been in the Avi Load Balancer cache for 5 minutes, the client knows that it must only cache the object locally for 5 more minutes.
Date Header - If a date header was not added by the server, then Avi Load Balancer will add a date header to the object served from its HTTP cache. This header indicates to the client when the object was originally sent by the server to the HTTP cache in Avi Load Balancer .
Aggressive - Enable or disable caching objects without Cache-Control headers.
Cacheable Object Size - The minimum and maximum size of an object to be cached, in bytes. Most objects smaller than 100 bytes are web beacons and must not be cached despite being image objects. Large objects, such as streamed videos can be cached, though it might not be appropriate and might saturate the cache size quickly.
Cache Expire Time - An intermediate cache must be able to guarantee that it is not serving stale content. If the server sends headers indicating how long the content can be cached (such as cache control), the Avi Load Balancer uses those values. If the server does not send expiration timeouts and the Avi Load Balancer is unable to make a strong determination of freshness, it stores the object for no longer than the duration of time specified by the Cache Expire Time.
Heuristic Expire - If a response object from the server does not include the Cache-Control header but includes an If-Modified-Since header, the Avi Load Balancer uses this time to calculate the cache-control expiration, which supersedes the Cache Expire Time setting for this object.
Cache URI with Query Arguments - This option allows caching of objects whose URI includes a query argument. Deactivating this option prevents caching these objects. When enabled, the request must match the URI query to be considered a hit. The following are two examples of URIs that include queries.:
www.search.com/search.asp?search=caching
www.foo.com/index.html?loginID=User
The first example might be a legitimate use case for caching a generic search, while the second, a unique request posing a security liability to the cache.
Cacheable Mime Types - Statically defines a list of cacheable object types. This can be a String Group, such as System-Cacheable-Resource-Types, or a custom comma-separated list of Mime types that the Avi Load Balancer must cache. If no Mime Types are listed in this field, the Avi Load Balancer by default assumes that any object is eligible for caching.
Non-Cacheable Mime Types- Statically defines a list of object types that are not cacheable. This creates an exclusion list that is the opposite of the cacheable list. An object listed in exclusion list is not cached.
Non-Cacheable URI -Non-cacheable URI confirguration with match critera.
