Symfony
sponsored by SensioLabs
Menu
  • About
  • Documentation
  • Screencasts
  • Cloud
  • Certification
  • Community
  • Businesses
  • News
  • Download
  1. Home
  2. Documentation
  3. Cookbook
  4. Cache
  5. How to use Varnish to speed up my Website
  • Documentation
  • Book
  • Reference
  • Bundles
  • Cloud
Search by Algolia

Table of Contents

  • Configuration
  • Cache Invalidation
  • Routing and X-FORWARDED Headers

How to use Varnish to speed up my Website

Edit this page

Warning: You are browsing the documentation for Symfony 2.2, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

How to use Varnish to speed up my Website

Because Symfony2's cache uses the standard HTTP cache headers, the HTTP Cache can easily be replaced with any other reverse proxy. Varnish is a powerful, open-source, HTTP accelerator capable of serving cached content quickly and including support for Edge Side Includes.

Configuration

As seen previously, Symfony2 is smart enough to detect whether it talks to a reverse proxy that understands ESI or not. It works out of the box when you use the Symfony2 reverse proxy, but you need a special configuration to make it work with Varnish. Thankfully, Symfony2 relies on yet another standard written by Akamaï (Edge Architecture), so the configuration tips in this chapter can be useful even if you don't use Symfony2.

Note

Varnish only supports the src attribute for ESI tags (onerror and alt attributes are ignored).

First, configure Varnish so that it advertises its ESI support by adding a Surrogate-Capability header to requests forwarded to the backend application:

1
2
3
4
sub vcl_recv {
    // Add a Surrogate-Capability header to announce ESI support.
    set req.http.Surrogate-Capability = "abc=ESI/1.0";
}

Then, optimize Varnish so that it only parses the Response contents when there is at least one ESI tag by checking the Surrogate-Control header that Symfony2 adds automatically:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
sub vcl_fetch {
    /*
    Check for ESI acknowledgement
    and remove Surrogate-Control header
    */
    if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
        unset beresp.http.Surrogate-Control;

        // For Varnish >= 3.0
        set beresp.do_esi = true;
        // For Varnish 

Caution

Compression with ESI was not supported in Varnish until version 3.0 (read GZIP and Varnish). If you're not using Varnish 3.0, put a web server in front of Varnish to perform the compression.

Cache Invalidation

You should never need to invalidate cached data because invalidation is already taken into account natively in the HTTP cache models (see HTTP Cache).

Still, Varnish can be configured to accept a special HTTP PURGE method that will invalidate the cache for a given resource:

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
39
40
41
/*
 Connect to the backend server
 on the local machine on port 8080
 */
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    /*
    Varnish default behaviour doesn't support PURGE.
    Match the PURGE request and immediately do a cache lookup,
    otherwise Varnish will directly pipe the request to the backend
    and bypass the cache
    */
    if (req.request == "PURGE") {
        return(lookup);
    }
}

sub vcl_hit {
    // Match PURGE request
    if (req.request == "PURGE") {
        // Force object expiration for Varnish = 3.0
        // purge;
        error 200 "Purged";
    }
}

sub vcl_miss {
    /*
    Match the PURGE request and
    indicate the request wasn't stored in cache.
    */
    if (req.request == "PURGE") {
        error 404 "Not purged";
    }
}

Caution

You must protect the PURGE HTTP method somehow to avoid random people purging your cached data. You can do this by setting up an access list:

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
39
40
41
42
43
44
45
46
/*
 Connect to the backend server
 on the local machine on port 8080
 */
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

// ACL's can contain IP's, subnets and hostnames
acl purge {
    "localhost";
    "192.168.55.0"/24;
}

sub vcl_recv {
    // Match PURGE request to avoid cache bypassing
    if (req.request == "PURGE") {
        // Match client IP to the ACL
        if (!client.ip ~ purge) {
            // Deny access
            error 405 "Not allowed.";
        }
        // Perform a cache lookup
        return(lookup);
    }
}

sub vcl_hit {
    // Match PURGE request
    if (req.request == "PURGE") {
        // Force object expiration for Varnish = 3.0
        // purge;
        error 200 "Purged";
    }
}

sub vcl_miss {
    // Match PURGE request
    if (req.request == "PURGE") {
        // Indicate that the object isn't stored in cache
        error 404 "Not purged";
    }
}

Routing and X-FORWARDED Headers

To ensure that the Symfony Router generates URLs correctly with Varnish, proper `X-Forwarded` headers must be added so that Symfony is aware of the original port number of the request. Exactly how this is done depends on your setup. As a simple example, Varnish and your web server are on the same machine and that Varnish is listening on one port (e.g. 80) and Apache on another (e.g. 8080). In this situation, Varnish should add the X-Forwarded-Port header so that the Symfony application knows that the original port number is 80 and not 8080.

If this header weren't set properly, Symfony may append 8080 when generating absolute URLs:

1
2
3
4
5
6
7
sub vcl_recv {
    if (req.http.X-Forwarded-Proto == "https" ) {
        set req.http.X-Forwarded-Port = "443";
    } else {
        set req.http.X-Forwarded-Port = "80";
    }
}

Note

Remember to configure framework.trusted_proxies in the Symfony configuration so that Varnish is seen as a trusted proxy and the X-Forwarded- headers are used.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
We stand with Ukraine.
Version:
Become certified from home

Become certified from home

Peruse our complete Symfony & PHP solutions catalog for your web development needs.

Peruse our complete Symfony & PHP solutions catalog for your web development needs.

↓ Our footer now uses the colors of the Ukrainian flag because Symfony stands with the people of Ukraine.

Avatar of Daniel Ancuta, a Symfony contributor

Thanks Daniel Ancuta (@whisller) for being a Symfony contributor

1 commit • 4 lines changed

View all contributors that help us make Symfony

Become a Symfony contributor

Be an active part of the community and contribute ideas, code and bug fixes. Both experts and newcomers are welcome.

Learn how to contribute

Symfony™ is a trademark of Symfony SAS. All rights reserved.

  • What is Symfony?
    • Symfony at a Glance
    • Symfony Components
    • Case Studies
    • Symfony Releases
    • Security Policy
    • Logo & Screenshots
    • Trademark & Licenses
    • symfony1 Legacy
  • Learn Symfony
    • Symfony Docs
    • Symfony Book
    • Reference
    • Bundles
    • Best Practices
    • Training
    • eLearning Platform
    • Certification
  • Screencasts
    • Learn Symfony
    • Learn PHP
    • Learn JavaScript
    • Learn Drupal
    • Learn RESTful APIs
  • Community
    • SymfonyConnect
    • Support
    • How to be Involved
    • Code of Conduct
    • Events & Meetups
    • Projects using Symfony
    • Downloads Stats
    • Contributors
    • Backers
  • Blog
    • Events & Meetups
    • A week of symfony
    • Case studies
    • Cloud
    • Community
    • Conferences
    • Diversity
    • Documentation
    • Living on the edge
    • Releases
    • Security Advisories
    • SymfonyInsight
    • Twig
    • SensioLabs
  • Services
    • SensioLabs services
    • Train developers
    • Manage your project quality
    • Improve your project performance
    • Host Symfony projects
    Deployed on
Follow Symfony
Search by Algolia