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
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-ControlHeader to public and
max-ageto an appropriate value.
- for non-cachable content you should set the
Cache-ControlHeader to one of these values (depending if the clients should be allowed to cache):
- responses with
Set-Cookiewill not be cached
- if there is no
Set-CookieHeader responses are cached with the default maximum settings (see next point)
- if there is no
- by default our load balancer caches a maximum time of 10 Minutes (lower values in the
Cache-Controlheader are honored) and will only store responds with HTTP 200 or 404 (for 1 minute).
PragmaHeader is not honored by default but can be enabled on request.
- on enabled caching our load balancer sets the
X-Proxy-Cacheheader 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.
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.