Posted over 1 year ago. Visible to the public.

Loadbalancer HTTP Cache

By using this technique, we are able to handle a six-digit amount of concurrent visitors to a Ruby-backed website.

Using the HTTP-Cache on our load balancers

Simple configuration

HTTP Caching is disabled by default. Please contact our operations team to enable it for your application. Once activated, the configuration the load balancer will interpret the Cache-Control Header. You have to set this header correctly in your application in order for the caching to work correctly. If this is not possible for some reason you need us to setup a special configuration for your caching (see next point).

  • for cacheable content you should set the Cache-Control Header to public and max-age to an appropriate value.
  • for non-cachable content you should set the Cache-Control Header to one of these values (depending if the clients should be allowed to cache): Private, No-Cache, or No-Store
  • responses with Set-Cookie will not be cached
    • if there is no Cache-Control Header or Set-Cookie Header responses are cached with the default maximum settings (see next point)
  • by default our load balancer caches a maximum time of 10 Minutes (lower values in the Cache-Control header are honored) and will only store responds with HTTP 200 or 404 (for 1 minute).
  • the Pragma Header is not honored by default but can be enabled on request.
  • on enabled caching our load balancer sets the X-Proxy-Cache header for responses so that you can see which requests were really cached.
  • by default cache responses (the so called Cache-Key) differ by the requested hostname and URI (including parameters). If your website returns different content for e.g. mobile and desktop user agents we need to configure this.
  • stale (outdated) cache content can also be delivered by our load balancer if the application servers are down (or not responsive). Also needs to be enabled separately.

Custom Configuration

The configuration options in our default setup should be suitable for the most use cases. However some applications need some adjustment in the configuration. There are many solutions for special requirements on caching but you can have a look at these examples of possible configuration:

  • cache only a specific location (URI)
  • cache specific URIs whatever the response headers say
  • adapt cache key for nearly every fact evaluable via HTTP-Headers
  • bypass cache on specific circumstances
  • use a custom header (response or request) for controlling cache behaviour
  • serve stale content
  • custom cache time
  • custom cache response codes

If you are not sure what is suitable for you don't hesitate to contact our operations team.

Owner of this card:

Avatar
Claus-Theodor Riegg
Last edit:
11 months ago
by Claus-Theodor Riegg
Posted by Claus-Theodor Riegg to opscomplete
This website uses cookies to improve usability and analyze traffic.
Accept or learn more