The Varnish cache system

Simple Hosting instances and Web Accelerators benefit from a powerful cache system powered by Varnish. This allows you to distribute the content of your website to a larger number of visitors without using the resources of your instance or server.

For example, when a website visitor requests a file from your web server 'foo.jpg', this file is placed into the Varnish cache. When the next visitor requests the same image, the image is served from the Varnish cache, relieving your web server from replying to the request.

Check cache status

Caching is enabled by default and an expiration period of 120 seconds is set for all requests.

You can control for how long an object should be cached, or whether it should be cached at all. You can also control whether different representations of the same object should be cached to respond to different request options. Learn more about controlling the cache in the following sections.

When you make an HTTP(s) request to a website hosted on Simple Hosting or linked to a Web Accelerator, you will notice that the response will contain specific headers that indicate whether caching is enabled or not.

You can use a variety of tools to see the HTTP headers in the responses. For example, you can use your browser's “Inspector” tool or the following command: curl -i http://example.com

All HTTP(s) requests, cached or not, go through our Varnish cache system, so you will always find the Via header (RFC) in the responses :

Via: 1.1 varnish

To determine whether your response is being cached, check if the Age: header has a value greater than 0. The following example shows a response that was served from the cache and was generated by the actual code 117 seconds ago:

Via: 1.1 varnish
Age: 117

Make multiple requests to the same address and see whether the Age: value increases, or stays at 0. If the object is not cached, the value will always be 0, meaning that it was served by the instance and not the Web Accelerator.

Otherwise, the value will increase until the cache expires as the object is being served by the Web Accelerator, or from your browser's cache directly, or from an intermediary proxy system such as your ISP or corporate proxy. After expiration, or after a purge, the value will be 0 for the first response.

Modify or deactivate the cache period

The default period an item will remain in the cache is 120 seconds. If you'd like to change this, you can do so by adding the following header and varying the value of max-age (in seconds):

HTTP Cache-Control: max-age=200

For development or testing purposes, you can reduce the cache to 1 second, with max-age=1. With max-age=0, the cache will be disabled, but be aware that the performance of your instance will be reduced without the cache system in place, and is not recommended. 

For example, in php:

header("Cache-Control: max-age=1");

Example for an .htaccess file if it is a static website:

Header add Cache-Control "max-age=1"

Example in node.js : (Works with the standard HTTP libraries and with the Express framework)

function (request, response) {
    response.setHeader('Cache-Control', 'max-age=1');
}

Advanced VPS customers: The Web Accelerator takes care of s-maxage

Purging cache using HTTP 'PURGE'/'PURGEALL' request

It is possible to purge a particular URL cache by sending an HTTP PURGE request. You can also purge the entire cache with an HTTP PURGEALL request.

The PURGE and PURGEALL requests will only work from within your Simple Hosting instance or Server. For the moment, they cannot be issued remotely.

For example, you can connect to your instance or server using the SSH console and run a curl command :

curl -X PURGE http://www.example.com/test/index.html
curl -X PURGEALL http://www.example.com/

Alternatively, here is a PHP script that can be called from a browser to clear a particular URL cache:

<?php
/* purge.php
 * Purge a URL on this host
 */
header("Cache-Control: max-age=1"); // don't cache ourself
 
error_reporting(E_ALL);
ini_set("display_errors", 1);
 
// Set to true to hide varnish result
define("SILENT", false);
 
$path = isset($_GET["path"]) ? $_GET["path"] : "";
 
$purge_url = "http://" . $_SERVER["HTTP_HOST"] . "/$path";
 
if ( $ch = curl_init($purge_url) ) {
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PURGE");
    curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);
    curl_setopt($ch, CURLOPT_NOBODY, SILENT);
 
    curl_exec($ch);
    curl_close($ch);
}
?>

For WordPress, we recommend using the Varnish HTTP Purge plugin.

Purging cache from web interface

It is possible to purge the cache directly from your Simple Hosting instance's administration page.

To do this, once you are on your instance's control panel, scroll down to the “Access” table, and where it says “Administration of your instance”, click on “Login”.

You will then be prompted for your user name (this is your instance's ID) and password (defined when you created the instance):

Once logged in, find the “Varnish” section, and click on the link to purge all objects in cache.

If you see “200 = OK” then this means that the purge was successful.

The PURGEALL command can only be performed every 120 seconds. This limitation is to prevent abuse of the cache CPU.

Purging cache when deploying a git branch

For Simple Hosting instances that are utilizing the built-in git repository, executing the deploy command will automatically perform a PURGEALL at the end of the deployment process.

mod_expires

Your instance includes the enabled mod_expires module in Apache2, which allows you to set custom expiration dates for cached items based on either the time the source file was last modified, or to the time of the client access. 

You can use the directive “ExpiresDefault”” to set an expiration time for all cached items, or you can set the expiration time for specific file-types using “ExpiresByType”.

For more information please see the mod_expires Apache2 documentation

The following cookies are stripped by Varnish:

cookies.vcl

#   
# sanitize cookies   
# 
                                                                                                   
sub vcl_recv {
	if (req.http.Cookie) {
	# Remove unwanted cookies set by javascript for external services
	# try to track origin                      
	# __utm* _ga _gat: Google Analytics, __gads: Google Adsense                  
	# __qca __qcb: Quantcast                                                             
	# _jsuid: GetClicky                                                                  
	# __cfduid: CloudFare                                                                
	# __unam __switchTo5x: ShareThis                                                     
	# __atuvc: AddThis  (_atshc also?)                                                   
	set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)_(ga(|t)|jsuid|_(utm[a-z]+|gads|qc(a|b)|cfduid|unam|switchTo5x|atuvc))=[^;]*", "");

	# Cleanup
		set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
		if (req.http.Cookie == "") {
			unset req.http.Cookie;
		}
	}
	# Track filtered cookie to analyse, can be removed                                                      
	#std.log("cookie:" + req.http.Cookie);                                                                             
}
Last modified: 08/01/2016 at 11:47 by Alexandre L. (Gandi)