Table of Contents
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 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'); }
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.
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); } ?>
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.
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
Cookie Stripping
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); }