~ubuntu-branches/debian/sid/varnish/sid

« back to all changes in this revision

Viewing changes to doc/sphinx/tutorial/purging.rst

  • Committer: Bazaar Package Importer
  • Author(s): Stig Sandbeck Mathisen
  • Date: 2011-03-21 10:16:07 UTC
  • mfrom: (24.1.2 experimental)
  • Revision ID: james.westby@ubuntu.com-20110321101607-528fzl583fqanas5
Tags: 2.1.5-2
ReleaseĀ forĀ unstable

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
.. _tutorial-purging:
 
2
 
 
3
Purging and banning
 
4
-------------------
 
5
 
 
6
One of the most effective way of increasing your hit ratio is to
 
7
increase the time-to-live (ttl) of your objects. But, as you're aware
 
8
of, in this twitterific day of age serving content that is outdated is
 
9
bad for business.
 
10
 
 
11
The solution is to notify Varnish when there is fresh content
 
12
available. This can be done through two mechanisms. HTTP purging and
 
13
bans. First, let me explain the HTTP purges. 
 
14
 
 
15
 
 
16
HTTP Purges
 
17
~~~~~~~~~~~
 
18
 
 
19
An HTTP purge is similar to a HTTP GET request, except that the
 
20
*method* is PURGE. Actually you can call the method whatever you'd
 
21
like, but most people refer to this as purging. Squid supports the
 
22
same mechanism. In order to support purging in Varnish you need the
 
23
following VCL in place:::
 
24
 
 
25
  acl purge {
 
26
          "localhost";
 
27
          "192.168.55.0/24";
 
28
  }
 
29
  
 
30
  sub vcl_recv {
 
31
          # allow PURGE from localhost and 192.168.55...
 
32
 
 
33
          if (req.request == "PURGE") {
 
34
                  if (!client.ip ~ purge) {
 
35
                          error 405 "Not allowed.";
 
36
                  }
 
37
                  return (lookup);
 
38
          }
 
39
  }
 
40
  
 
41
  sub vcl_hit {
 
42
          if (req.request == "PURGE") {
 
43
                  # Note that setting ttl to 0 is magical.
 
44
                  # the object is zapped from cache.
 
45
                  set obj.ttl = 0s;
 
46
                  error 200 "Purged.";
 
47
          }
 
48
  }
 
49
  
 
50
  sub vcl_miss {
 
51
          if (req.request == "PURGE") {
 
52
 
 
53
                  error 404 "Not in cache.";
 
54
          }
 
55
  }
 
56
 
 
57
As you can see we have used to new VCL subroutines, vcl_hit and
 
58
vcl_miss. When we call lookup Varnish will try to lookup the object in
 
59
its cache. It will either hit an object or miss it and so the
 
60
corresponding subroutine is called. In vcl_hit the object that is
 
61
stored in cache is available and we can set the TTL.
 
62
 
 
63
So for vg.no to invalidate their front page they would call out to
 
64
Varnish like this:::
 
65
 
 
66
  PURGE / HTTP/1.0
 
67
  Host: vg.no
 
68
 
 
69
And Varnish would then discard the front page. If there are several
 
70
variants of the same URL in the cache however, only the matching
 
71
variant will be purged. To purge a gzip variant of the same page the
 
72
request would have to look like this:::
 
73
 
 
74
  PURGE / HTTP/1.0
 
75
  Host: vg.no
 
76
  Accept-Encoding: gzip
 
77
 
 
78
Bans
 
79
~~~~
 
80
 
 
81
There is another way to invalidate content. Bans. You can think of
 
82
bans as a sort of a filter. You *ban* certain content from being
 
83
served from your cache. You can ban content based on any metadata we
 
84
have.
 
85
 
 
86
Support for bans is built into Varnish and available in the CLI
 
87
interface. For VG to ban every png object belonging on vg.no they could
 
88
issue:::
 
89
 
 
90
  purge req.http.host == "vg.no" && req.http.url ~ "\.png$"
 
91
 
 
92
Quite powerful, really.
 
93
 
 
94
Bans are checked when we hit an object in the cache, but before we
 
95
deliver it. An object is only checked against newer bans. If you have
 
96
a lot of objects with long TTL in your cache you should be aware of a
 
97
potential performance impact of having many bans.
 
98
 
 
99
You can also add bans to Varnish via HTTP. Doing so requires a bit of VCL.::
 
100
 
 
101
  sub vcl_recv {
 
102
          if (req.request == "BAN") {
 
103
                  # Same ACL check as above:
 
104
                  if (!client.ip ~ purge) {
 
105
                          error 405 "Not allowed.";
 
106
                  }
 
107
                  purge("req.http.host == " req.http.host 
 
108
                        "&& req.url == " req.url);
 
109
 
 
110
                  # Throw a synthetic page so the
 
111
                  # request wont go to the backend.
 
112
                  error 200 "Ban added"
 
113
          }
 
114
  }
 
115
 
 
116
This VCL sniplet enables Varnish to handle a HTTP BAN method. Adding a
 
117
ban on the URL, including the host part.
 
118
 
 
119