Varnish Cache usually works the best out of the box. However, minimum tweaks and optimization can make Varnish to work better with WordPress. When we are talking bout WordPress, obviously W3 Total Cache configuration comes in to question – because W3 Total Cache has separate option for configuring W3 Total Cache for Varnish. So, how should we pass the page requests to get the maximum out from Varnish Cache? Read Get Started with Varnish Cache for setting up of Varnish Cache in case you have not installed Varnish Cache yet. We are writing the things divided in to two sub headers – general tweaks and specific for WordPress with W3 Total Cache configuration.
Advanced Tweaks and Optimization for Varnish Cache
So, actually we are serving content via Varnish Cache – not Apache2 and PHP handlers directly. In the previous guide we changed the port of Varnish to 8080, if we kept it to default; if your server’s IP was 125.23.24.987, if you point towards :
1 | http://125.23.24.987:6081 |
You should be able to view a copy of the webpage. In fact, you can keep it to default and make Apache2 to Listen at port 80 and Port 8080. Virtual Host, in that case should handle port 8080 only. This works great for adding load balancer – read Load Balancer Service from Rackspace Guide. Load balancer should Listen with http:80 method, use Round Robin Algorithm and as node; your server’s port 6081 should serve the content to load balancer. As load balancer has a different IP and we can control access precisely, by no way any request will go directly to Apache2 and PHP handlers directly. You domain example.com is fully cached. But, for WordPress we need to keep the Admin area cache free :
---
1 2 3 4 5 6 7 8 9 10 11 12 13 | nano /etc/varnish/user.vcl # Edit the file like below sub vcl_recv { if (req.http.host ~ "example.com" || req.url ~ "^/admin") { return (pass); } } # restart, varnish should be reloaded first service varnish restart service apache2 reload |
You might face Guru Meditation Error with improper setup.
This editing will work great for the most :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | backend default { .host = "127.0.0.1"; # backend .port = "8080"; # Port of backend .probe = { .url = "/"; .timeout = 34ms; .interval = 1s; .window = 10; .threshold = 8; } } sub vcl_recv { # for WordPress the admin area if (req.http.host ~ "example.com" || req.url ~ "^/admin" || req.http.Cookie ~ "logged_in" || req.request == "POST") { return (pass); } # Set / unset cookies unset req.http.Cookie; # Set Grace Time to one hour set req.grace = 1h; } sub vcl_fetch { # Set the TTL for cache object set beresp.ttl = 5m; # Set Grace Time set beresp.grace = 1h; } |
You can read the docs :
1 | https://www.varnish-cache.org/docs/2.1/index.html |
Advanced Tweaks and Optimization for Varnish Cache : For WordPress
It actually does not matter whether you are configuring W3 Total Cache with Varnish or not as long you are serving content via a load balancer – W3 Total Cache can not give much higher performance with our setup.
Yet, if you want to add the servers, add main server’s IP where Varnish is running. For multiple server, the configuration would be more complicated if you involve W3 Total Cache :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | # taken from highscalability.com # written by Jeff backend server1 { .host = "10.0.0.10"; } backend server2{ .host = "10.0.0.11"; } director multi_servers1 round-robin { { .backend = server1; } { .backend = server2; } } director multi_servers2 random { { .backend = server1; } { .backend = server2; } } |
There is enough change that, W3TC or any PHP script would not follow the logic and ultimately you’ll end up serving 503 pages. You can end up complicating the simple setup :
1 | http://wordpress.org/support/topic/plugin-w3-total-cache-varnish-cache-not-purged-sends-get-requests-instead-of-purge |
For our way of guide with Rackspace Cloud Server and Loadbalancer, we need not to involve Varnish Cache.
