-
Notifications
You must be signed in to change notification settings - Fork 47
Varnish
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.
This plugin enables your WordPress site to communicate with Varnish to dynamically empty the cache for any and all updated content. It does not install nor manage your Varnish configuration.
The Sample VCLs are provided with no support.
To purge a URL means to empty the cache for that page. It is also sometimes called 'banning'
To manually purge a page: curl -X PURGE https://example.com
To purge wildcard: curl -X PURGE https://example.com/.*
If you're using a proxy (like Cloudflare or Sucuri), you'll need some variant of this: curl -X PURGE "https://123.45.67.89/" -H "host:www.example.com"
You've probably seen that error at least once. A 503 error means that the web server trying to be reached is unavailable - this could be because it is overloaded, down for maintenance, or not fully functional for another reason.
The primary issues (and their causes) are as follows:
- Backend fetch failed -- Memory issues
- Service unavailable -- Apache and/or MySQL
In the case of memory related issues, the best bet is to disable as many plugins as possible. If that doesn't help, try swapping them to the default theme.
Always make sure themes and plugins are updated! This can be tricky with non WordPress.org hosted code, so you'll need to be on the ball. If your theme or plugin hasn't been updated in a couple years, it's likely the cause.
If you need to open a ticket with your webhost, please include the XID value on the page. They can use that to debug.
If you want to test if Varnish is working, go to Tools -> Varnish Status for a very simple test.
If you're command line savvy, you can monitor the interactions between the plugin and Varnish. This can help you understand what's not working quite right, but it can very confusing.
Command line tools require you to log in as the user account who runs Varnish, as of version 6.0. If you cannot access the following commands, open a ticket with your webhost for assistance.
If you have the XID from the error, you can use that to find the specific log entry:
$ varnishlog -d -q "vxid == 123456"
From that, look for the value for FetchError:
- FetchError backend default: fail errno 110 (Connection timed out)
If you don't have the XID, you will need to find the relevant log entries in varnishlog to give you a clue. Since varnishlog logs a lot of data it might be hard to track the entries down. You can set varnishlog to log all your 503 errors by issuing the following command:
$ varnishlog -q 'RespStatus == 503' -g request
If the error happened just a short time ago the transaction might still be in the shared memory log segment. To get varnishlog to process the whole shared memory log just add the ‘-d’ parameter:
$ varnishlog -d -q 'RespStatus == 503' -g request
Please see the vsl-query and varnishlog man pages for elaborations on further filtering capabilities and explanation of the various options.
To see every request made to varnish, use this:
varnishncsa -F "%m %U"
A full Varnish flush looks like this:
PURGE /.*