|
| 1 | +.. index:: |
| 2 | + single: Cache; Varnish |
| 3 | + |
| 4 | +How to use Varnish to speedup my Website |
| 5 | +======================================== |
| 6 | + |
| 7 | +Because Symfony2's cache uses the standard HTTP cache headers, the |
| 8 | +:ref:`symfony-gateway-cache` can easily be replaced with any other reverse |
| 9 | +proxy. Varnish is a powerful, open-source, HTTP accelerator capable of serving |
| 10 | +cached content quickly and including support for :ref:`Edge Side |
| 11 | +Includes<edge-side-includes>`. |
| 12 | + |
| 13 | +.. index:: |
| 14 | + single: Varnish; configuration |
| 15 | + |
| 16 | +Configuration |
| 17 | +------------- |
| 18 | + |
| 19 | +As seen previously, Symfony2 is smart enough to detect whether it talks to a |
| 20 | +reverse proxy that understands ESI or not. It works out of the box when you |
| 21 | +use the Symfony2 reverse proxy, but you need a special configuration to make |
| 22 | +it work with Varnish. Thankfully, Symfony2 relies on yet another standard |
| 23 | +written by Akamaï (`Edge Architecture`_), so the configuration tips in this |
| 24 | +chapter can be useful even if you don't use Symfony2. |
| 25 | + |
| 26 | +.. note:: |
| 27 | + |
| 28 | + Varnish only supports the ``src`` attribute for ESI tags (``onerror`` and |
| 29 | + ``alt`` attributes are ignored). |
| 30 | + |
| 31 | +First, configure Varnish so that it advertises its ESI support by adding a |
| 32 | +``Surrogate-Capability`` header to requests forwarded to the backend |
| 33 | +application: |
| 34 | + |
| 35 | +.. code-block:: text |
| 36 | +
|
| 37 | + sub vcl_recv { |
| 38 | + set req.http.Surrogate-Capability = "abc=ESI/1.0"; |
| 39 | + } |
| 40 | +
|
| 41 | +Then, optimize Varnish so that it only parses the Response contents when there |
| 42 | +is at least one ESI tag by checking the ``Surrogate-Control`` header that |
| 43 | +Symfony2 adds automatically: |
| 44 | + |
| 45 | +.. code-block:: text |
| 46 | +
|
| 47 | + sub vcl_fetch { |
| 48 | + if (beresp.http.Surrogate-Control ~ "ESI/1.0") { |
| 49 | + unset beresp.http.Surrogate-Control; |
| 50 | + esi; |
| 51 | + } |
| 52 | + } |
| 53 | +
|
| 54 | +.. caution:: |
| 55 | + |
| 56 | + Don't use compression with ESI as Varnish won't be able to parse the |
| 57 | + response content. If you want to use compression, put a web server in |
| 58 | + front of Varnish to do the job. |
| 59 | + |
| 60 | +.. index:: |
| 61 | + single: Varnish; Invalidation |
| 62 | + |
| 63 | +Cache Invalidation |
| 64 | +------------------ |
| 65 | + |
| 66 | +You should never need to invalidate cached data because invalidation is already |
| 67 | +taken into account natively in the HTTP cache models (see :ref:`http-cache-invalidation`). |
| 68 | + |
| 69 | +Still, Varnish can be configured to accept a special HTTP ``PURGE`` method |
| 70 | +that will invalidate the cache for a given resource: |
| 71 | + |
| 72 | +.. code-block:: text |
| 73 | +
|
| 74 | + sub vcl_hit { |
| 75 | + if (req.request == "PURGE") { |
| 76 | + set obj.ttl = 0s; |
| 77 | + error 200 "Purged"; |
| 78 | + } |
| 79 | + } |
| 80 | +
|
| 81 | + sub vcl_miss { |
| 82 | + if (req.request == "PURGE") { |
| 83 | + error 404 "Not purged"; |
| 84 | + } |
| 85 | + } |
| 86 | +
|
| 87 | +.. caution:: |
| 88 | + |
| 89 | + You must protect the ``PURGE`` HTTP method somehow to avoid random people |
| 90 | + purging your cached data. |
0 commit comments