NSX Advanced Load Balancer caches HTTP content, thereby enabling faster page load times for clients and reduced workloads for both servers and NSX Advanced Load Balancer.

When a server sends a response (for example, logo.png), NSX Advanced 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 NSX Advanced 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. NSX Advanced Load Balancer does not need to compress every object every time, greatly reducing the compression workload.

Responses Eligible for Caching

When caching is enabled, NSX Advanced Load Balancer caches HTTP objects for the following types of responses:


  • GET, HEAD methods

  • 200 status code

NSX Advanced 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 NSX Advanced Load Balancer.

Responses Not Cached

NSX Advanced 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 NSX Advanced Load Balancer Monitoring and Operability Guide.

Cache Size

The size of a cache is indirectly determined based on the memory allocation for a Service Engine handling a virtual service that has caching enabled. This is determined within the SE Group properties through the connection memory slider. Memory allocated to buffers is used for TCP buffering (and hence accelerating), HTTP request and response buffering, and also for HTTP cache.

Cache Configuration Options

HTTP caching is enabled within the Application Profile of Type HTTP.

Navigate to Template > Profile > Application > Create. 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 - NSX Advanced 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 - NSX Advanced 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 NSX Advanced 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 NSX Advanced 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 NSX Advanced 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 NSX Advanced Load Balancer uses those values. If the server does not send expiration timeouts and the NSX Advanced 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 NSX Advanced 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 NSX Advanced Load Balancer must cache. If no Mime Types are listed in this field, the NSX Advanced 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.