Skip to content

Caching

Caching is essential for the scalability of a dynamic website. Depending on the complexity of the site, it is increasingly difficult to provide good performance for requests that reach to be handled by PHP. In general, there are orders of magnitude of difference between the latency of a response that comes from the cache and one that comes from the backend. Moreover, a caching mechanism may be necessary to mitigate denial of service attacks.

The Web Accelerator combines Varnish configuration modules developed and refined over years of experience with customizations necessary for the client's site to achieve maximum possible efficiency. It is a product entirely managed by Seeweb staff, without the need for the client to configure it personally.

Caching Modes

It is necessary to decide on a caching policy: the goal is to cache as many responses as possible (to increase efficiency), but never do it when it's not allowed (so as not to break site functions).

In the default mode, the Web Accelerator follows the normal HTTP semantics. This mode is usually not useful, at least without a customized configuration, because HTTP prohibits caching responses that receive or emit cookies and generally all requests have them.

"Standard" Caching: as an evolution of the previous, cookies can be ignored for objects that are assumed to be static, and thus force their caching: images, CSS, JavaScript, fonts, etc... A configuration of this type works without the need for customizations, but does not cache dynamic pages and therefore does not allow for the best performance.

"Forced" Caching: caching of all objects except those explicitly excluded, such as the site's admin area or shopping cart. Requires detailed knowledge of the CMS or the specific site, but an accurate configuration allows for optimal caching level. The Web Accelerator automatically handles the most common cases thanks to a library of configuration modules already ready for the most popular CMS like WordPress, Joomla, and Magento.

It is also possible to use more complex criteria than the URL to exclude something from caching: for instance, the Web Accelerator can examine the cookies to know if a request was made by an authenticated user, who therefore must receive a personalized page.

Moreover, the information contained in cookies can be used to partition the cache and have multiple copies of the same page personalized according to characteristics such as language, currency, or even each authenticated user.

Caching of Responses

TTL of Cached Objects

The Web Accelerator caches objects for the time prescribed by the Cache-Control headers returned by the backend, up to a maximum duration (default: 1 day).

In the absence of the header, a predefined TTL is applied based on the file extension in the URL: for assumed static objects (images, CSS, JavaScript, fonts, etc.) this value is 1 hour, while for assumed dynamic pages (i.e., everything else) it is 5 minutes. Errors like 403 and 404 are cached for 1 minute.

If it's not possible for the backend to send appropriate Cache-Control headers, it is still possible to configure customized policies on the Web Accelerator with maximum granularity. Our staff is available to evaluate the best settings for each site.

If the backend fails and it is not possible to update the cache, the Web Accelerator responds with expired objects up to one hour earlier.

It is therefore emphasized that if the backend sends objects with headers like Cache-Control: no-cache, it will prevent caching: in this case, if it's not possible to correct its operation, the Web Accelerator can be configured to ignore them completely.

Cache Invalidation

There are three different APIs available to invalidate the cache content:

  • requests for specific objects using the HTTP PURGE method.
  • objects matching a regular expression requested with the HTTP PURGE method, adding a X-Purge-Method: regex header.
  • the Drupal Invalidation API, without needing to set X-Varnish-Secret.

To automatically manage invalidation in WordPress, you can install a plugin that implements one of these interfaces, such as Proxy Cache Purge.

A sample file test_purge.php is available that shows how to invalidate an object with PHP and libcurl.

Temporary Deactivation of Caching

During development activities that directly involve the site in production, it is possible to deactivate caching for the current session in the browser by accessing https://<domain>/seeweb-wa/cache-bypass.

High Availability

Local: two instances can be activated in the same data center in active/passive mode.

Geographical anycast: instances can be activated in different data centers that each manage a portion of the traffic, and in the event of failure or maintenance, they can back each other up.

Seeweb has data centers in Milan and Frosinone with independent connectivity and peering, allowing local visitors to be served with low latency.

For very high traffic sites, it is also possible to activate multiple instances in various configurations in the same data center in active/active mode, although this is very rarely necessary.

Emergency Caching

Sometimes a client's site unexpectedly receives a large amount of traffic, whether legitimate or as part of a Denial of Service attack.

The Seeweb staff can activate an emergency Web Accelerator in just a few minutes, redirecting with flowspec the HTTP and HTTPS traffic that would normally be directed to the backend. This way, there is no need to change the site's IP in the DNS and wait for all clients to see the new one.

The emergency cache is an almost standard Web Accelerator. It can directly send the traffic for sites it is not configured to handle to the backend, so it is only necessary to install certificates for the sites that actually need caching.

Real-Time Statistics

https://<domain>/seeweb-wa/statistics shows real-time statistics on the traffic of the entire Web Accelerator. The credentials are provided at the time of activation.