Tuning Varnish startup parameters

thread_pools = (Number of CPU cores)
thread_pool_min = (800 / Number of CPU cores)
thread_pool_max = 4000
timeout_linger = 50
malloc,(yourmemory - 20%)G

Varnish4: Cache all!

Varnish offers great capabilities to manipulate requests coming from the backend servers.

The following example let you cache all request despite from what is coming from the backend servers.

sub vcl_backend_response {  

     # client browser and server cache  
     # Force cache: remove expires, Cache-control & Pragma header coming from the backend  
     if (beresp.http.Cache-Control ~ "(no-cache|private)" || beresp.http.Pragma ~ "no-cache") {  
         unset beresp.http.Expires;  
         unset beresp.http.Cache-Control;  
         unset beresp.http.Pragma;  

         # Marker for vcl_deliver to reset Age: /  
         set beresp.http.magicmarker = "1";  

         # Leveraging browser, cache set the clients TTL on this object /  
         set beresp.http.Cache-Control = "public, max-age=60";  

         # cache set the clients TTL on this object /  
         set beresp.ttl = 1m;  

         # Allow stale content, in case the backend goes down.  
         # make Varnish keep all objects for 6 hours beyond their TTL  
         set beresp.grace = 6h;  
         return (deliver);  
sub vcl_deliver {  

     # Called before a cached object is delivered to the client.  
     if (resp.http.magicmarker) {  
     unset resp.http.magicmarker;  

     # By definition we have a fresh object  
     set resp.http.Age = "0";  

     if (obj.hits > 0) { # Add debug header to see if it's a HIT/MISS and the number of hits, disable when not needed  
     set resp.http.X-Cache = "HIT";  
     } else { set resp.http.X-Cache = "MISS"; }  

     # Please note that obj.hits behaviour changed in 4.0, now it counts per objecthead, not per object  
     # and obj.hits may not be reset in some cases where bans are in use. See bug 1492 for details.  
     # So take hits with a grain of salt  
     set resp.http.X-Cache-Hits = obj.hits; 
     # Set Varnish server name  
     set resp.http.X-Served-By = server.hostname;  

     # Remove some headers: PHP version  
     unset resp.http.X-Powered-By;  

     # Remove some headers: Apache version & OS  
     unset resp.http.Server;  
     unset resp.http.X-Varnish;  
     unset resp.http.Via;  
     unset resp.http.Link;  
     unset resp.http.X-Generator;  
     return (deliver);  

Varnish High Availability (VHA) 1.2 released

Varnish Software just released a new version of Varnish High Avalability (VHA) 1.2 that boosts the following features plus some bug fixes in order to bring cache setups to be more efficiente and resilient:

ESI support: if you use dynamic content with Varnish, you are probably familiar with ESI. It allows you to include various objects inside a page on the server-side, letting Varnish build content using cached objects. VHA is now able to replicate this content, including all the multiple sub-requests caused by it, giving you replication without losing granularity in your content.

Better job scheduling: With v1.1 we gained support for multiple neighbors, but it was still a bit wild west-y, and in some circumstances, a slow neighbor could slow the replication for the other, well-behaved servers. This limitation has been fixed, letting the fast guys be fast no matter what.

Better autoscaling integration: VHA used to be very picky about its configuration file. Now it’s smarter and allows you to run/reload without neighbors for example. This permits an easier management of elastic clusters, a very popular setup. While not exactly part of VHA, I’d like to point out that we now have a ready-made solution to reconfigure automatically your VHA setup in a elastic cluster context. So if a neighbor is taken down or pops up, we’ll now and act on it.

Strict mode: Tight discipline also has its merits, and in a fixed setup, you may want to keep the old, picky behaviour as an effective error detection mechanism. Well, you can! You only need to activate an option, and you’re set.

Optional node name: VHA is able to use the hostname of the machine as it node name, making the ‘-m’ switch optional, and above all, adding genericity to the configuration.

In order to update just do the following:

 # Update and verify that installed vha-agent is version 1.2.1
yum update -y varnish-plus-ha 

This should be the correct results:

Varnish High Availability Agent 1.2
Varnish High Availability Agent 1.2

SSL in Varnish Cache Plus

Varnish Software announced that they finished implementing SSL in Varnish Cache Plus.

The release will happen at at Varnish summit in Silicon Valley in early June.

Varnish Cache Plus is both a HTTP server and a HTTP client and both implementations will have SSL enabled. The HTTP Server, ie the client facing SSL is perhaps the most significant one, enabling Varnish Cache Plus to encrypt traffic between the client and Varnish.

Read more at: SSL in Varnish Cache Plus