By using an HTTP cache, it is possible for us 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 Show archive.org snapshot . You have to set this header correctly in your application in order for the caching to work. If this is not possible for some reason we can setup a special configuration for your caching (see below).

• 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 sometimes the configuration needs to be adjusted. 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.