Commit a15f37d3 authored by Poul-Henning Kamp's avatar Poul-Henning Kamp
parents 4c18047e f8dd5ccc
......@@ -33,11 +33,11 @@ How...
That depends on pretty much everything.
I think our best current guidance is that you go for a cost-effective
RAM configuration, something like 1-16GB, and a SSD disk.
RAM configuration, something like 1-16GB, and an SSD.
Unless you positively know that you will need it, there is
little point in spendng a fortune on a hand-sewn motherboard
that can fit several TB in special RAM blocks, rivetet together
little point in spending a fortune on a hand-sewn motherboard
that can fit several TB in special RAM blocks, riveted together
by leftover watch-makers in Switzerland.
On the other hand, if you plot your traffic in Gb/s, you probably
......@@ -65,14 +65,14 @@ Refreshing is often called `purging <http://dictionary.reference.com/browse/PURG
From the command line you can write::
url.purge ^/$
ban.url ^/$
to purge your / document. As you might see url.purge takes an `regular expression <http://en.wikipedia.org/wiki/Regular_expression>`_
as its argument. Hence the ``^`` and ``$`` at the front and end. If the ``^`` is ommited, all the documents ending in a ``/`` in the cache would be deleted.
to ban your / document. As you might see ban.url takes an `regular expression <http://en.wikipedia.org/wiki/Regular_expression>`_
as its argument. Hence the ``^`` and ``$`` at the front and end. If the ``^`` is omitted, all the documents ending in a ``/`` in the cache would be deleted.
So to delete all the documents in the cache, write::
url.purge .*
ban.url .
at the command line.
......@@ -96,15 +96,15 @@ At the shell command line, type::
**How can I rewrite URLS before they are sent to the backend?**
You can use the ``regsub()`` function to do this. Here's an example for zope, to rewrite URL's for the virtualhostmonster::
You can use the ``regsub()`` function to do this. Here's an example for zope, to rewrite URLs for the virtualhostmonster::
if (req.http.host ~ "^(www.)?example.com") {
set req.url = regsub(req.url, "^", "/VirtualHostBase/http/example.com:80/Sites/example.com/VirtualHostRoot");
}
**I have a site with many hostnames, how do I keep them from multiplying the cache?**
**I have a site with many host names, how do I keep them from multiplying the cache?**
You can do this by normalizing the ``Host`` header for all your hostnames. Here's a VCL example::
You can do this by normalizing the ``Host`` header for all your host names. Here's a VCL example::
if (req.http.host ~ "^(www.)?example.com") {
set req.http.host = "example.com";
......@@ -120,7 +120,7 @@ You can use the ``bereq`` object for altering requests going to the backend, but
**How do I force the backend to send Vary headers?**
We have anectdotal evidence of non-RFC2616 compliant backends, which support content negotiation, but which do not emit a Vary header, unless the request contains Accept headers.
We have anecdotal evidence of non-RFC2616 compliant backends, which support content negotiation, but which do not emit a Vary header, unless the request contains Accept headers.
It may be appropriate to send no-op Accept headers to trick the backend into sending us the Vary header.
......@@ -177,8 +177,8 @@ Where...
**Can I find varnish for my operating system?**
We know that Varnish has been packaged for Debian, Ubuntu, RHEL,
Centos, (Open)SuSE, Gentoo and FreeBSD, possibly more. Check whatever
packagemanager you use. Or read :ref:`Installing Varnish on your computer <install-doc>`.
CentOS, (Open)SUSE, Gentoo and FreeBSD, possibly more. Check whatever
package manager you use. Or read :ref:`Installing Varnish on your computer <install-doc>`.
Can I...
========
......@@ -211,7 +211,7 @@ Yes, as long as you give them different TCP ports and different ``-n``
arguments, you will be fine.
**Can I cache multiple vhosts with one Varnish?**
**Can I cache multiple virtual hosts with one Varnish?**
Yes, that works right out of the box.
......@@ -228,7 +228,7 @@ Besides, the output is a lot less useful than you might think.
Not at present, and while we keep an eye on this, there are no
current plans to add HTTPS support, until we can find a way where
it adds significant value, relative to running a stand-alone
HTTPS proxy such as ngnix or pound.
HTTPS proxy such as nginx or pound.
**Can Varnish load balance between multiple backends?**
......@@ -259,10 +259,10 @@ There are 2 common reasons for this:
**Why are regular expressions case-sensitive?**
Some HTTP headers, such as ``Host:`` and ``Location:``
contain FQDN's which by definition is not case-sensitive. Other
HTTP headers are case-sensitive, most notably the URLs. Therefore
a "one size fits all" solution is not possible.
Some HTTP headers, such as ``Host:`` and ``Location:`` contain fully
qualified domain names, which by definition is not case-sensitive.
Other HTTP headers are case-sensitive, most notably the URLs.
Therefore a "one size fits all" solution is not possible.
In previous releases, we used the POSIX regular expressions
supplied with the operating system, and decided, because the
......@@ -272,12 +272,12 @@ they should not be case-sensitive.
From version 2.1.0 and forward, we use PCRE regular expressions,
where it *is* possible to control case-sensitivity in the
individual regular expressions, so we decided that it would
probably confuse people if we made the default case-insentive.
probably confuse people if we made the default case-insensitive.
(We promise not to change our minds about this again.)
To make a PCRE regex case insensitive, put ``(?i)`` at the start::
if (req.http.host ~ "?iexample.com$") {
if (req.http.host ~ "(?i)example.com$") {
...
}
......@@ -295,7 +295,7 @@ See the `PCRE man pages <http://www.pcre.org/pcre.txt>`_ for more information.
**Why does the ``Via:`` header say 1.1 in Varnish 2.1.x?**
The number in the ``Via:`` header is the HTTP protocol version
supported/applied, not the softwares version number.
supported/applied, not the software's version number.
**Why did you call it *Varnish*?**
......@@ -336,14 +336,14 @@ Varnish has a feature called **hit for pass**, which is used when Varnish gets a
* Worker returns object to varnish which turns out to be non-cacheable.
* Client 2..N are now given the **hit for pass** object instructing them to go to the backend
The **hit for pass** object will stay cached for the duration of it's ttl. This means that subsequent clients requesting /foo will be sent straight to the backend as long as the **hit for pass** object exists.
The **hit for pass** object will stay cached for the duration of its ttl. This means that subsequent clients requesting /foo will be sent straight to the backend as long as the **hit for pass** object exists.
The :command:`varnishstat` can tell you how many **hit for pass** objects varnish has served. You can lower the ttl for such an object if you are sure this is needed, using the following logic::
sub vcl_fetch {
if (!obj.cacheable) {
# Limit the lifetime of all 'hit for pass' objects to 10 seconds
obj.ttl = 10s;
pass;
return(hit_for_pass);
}
}
......@@ -120,7 +120,7 @@ ban.url regexp
Immediately invalidate all documents whose URL matches the
specified regular expression. Please note that the Host part of
the URL is ignored, so if you have several virtual hosts all of
them will be purged. Use *ban* to specify a complete ban if you
them will be banned. Use *ban* to specify a complete ban if you
need to narrow it down.
quit
......@@ -280,16 +280,16 @@ EXAMPLES
========
Simple example: All requests where req.url exactly matches the string
/news are purged from the cache:::
/news are banned from the cache:::
req.url == "/news"
Example: Purge all documents where the name does not end with ".ogg",
Example: Ban all documents where the name does not end with ".ogg",
and where the size of the object is greater than 10 megabytes:::
req.url !~ "\.ogg$" && obj.size > 10MB
Example: Purge all documents where the serving host is "example.com"
Example: Ban all documents where the serving host is "example.com"
or "www.example.com", and where the Set-Cookie header received from
the backend contains "USERID=1663":::
......
......@@ -323,8 +323,8 @@ regsub(str, regex, sub)
regsuball(str, regex, sub)
As regsuball() but this replaces all occurrences.
purge_url(regex)
Purge all objects in cache whose URLs match regex.
ban_url(regex)
Ban all objects in cache whose URLs match regex.
Subroutines
~~~~~~~~~~~
......@@ -523,7 +523,7 @@ Example:::
# in file "main.vcl"
include "backends.vcl";
include "purge.vcl";
include "ban.vcl";
# in file "backends.vcl"
sub vcl_recv {
......@@ -534,11 +534,11 @@ Example:::
}
}
# in file "purge.vcl"
# in file "ban.vcl"
sub vcl_recv {
if (client.ip ~ admin_network) {
if (req.http.Cache-Control ~ "no-cache") {
purge_url(req.url);
ban_url(req.url);
}
}
}
......@@ -858,14 +858,15 @@ for object invalidation:::
sub vcl_hit {
if (req.request == "PURGE") {
set obj.ttl = 0s;
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
error 404 "Not in cache.";
purge;
error 200 "Purged.";
}
}
......
.. _tutorial-purging:
Purging and banning
-------------------
=====================
Purging and banning
=====================
One of the most effective way of increasing your hit ratio is to
increase the time-to-live (ttl) of your objects. But, as you're aware
......@@ -14,7 +15,7 @@ bans. First, let me explain the HTTP purges.
HTTP Purges
~~~~~~~~~~~
===========
An HTTP purge is similar to an HTTP GET request, except that the
*method* is PURGE. Actually you can call the method whatever you'd
......@@ -40,17 +41,15 @@ following VCL in place::
sub vcl_hit {
if (req.request == "PURGE") {
# Note that setting ttl to 0 is magical.
# the object is zapped from cache.
set obj.ttl = 0s;
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
error 404 "Not in cache.";
purge;
error 200 "Purged.";
}
}
......@@ -60,23 +59,17 @@ its cache. It will either hit an object or miss it and so the
corresponding subroutine is called. In vcl_hit the object that is
stored in cache is available and we can set the TTL.
So for vg.no to invalidate their front page they would call out to
Varnish like this::
So for example.com to invalidate their front page they would call out
to Varnish like this::
PURGE / HTTP/1.0
Host: vg.no
Host: example.com
And Varnish would then discard the front page. If there are several
variants of the same URL in the cache however, only the matching
variant will be purged. To purge a gzip variant of the same page the
request would have to look like this::
PURGE / HTTP/1.0
Host: vg.no
Accept-Encoding: gzip
And Varnish would then discard the front page. This will remove all
variants as defined by Vary.
Bans
~~~~
====
There is another way to invalidate content. Bans. You can think of
bans as a sort of a filter. You *ban* certain content from being
......@@ -84,10 +77,10 @@ served from your cache. You can ban content based on any metadata we
have.
Support for bans is built into Varnish and available in the CLI
interface. For VG to ban every png object belonging on vg.no they could
issue::
interface. For VG to ban every png object belonging on example.com
they could issue::
purge req.http.host == "vg.no" && req.http.url ~ "\.png$"
ban req.http.host == "example.com" && req.http.url ~ "\.png$"
Quite powerful, really.
......@@ -104,7 +97,7 @@ You can also add bans to Varnish via HTTP. Doing so requires a bit of VCL::
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
purge("req.http.host == " req.http.host
ban("req.http.host == " req.http.host
"&& req.url == " req.url);
# Throw a synthetic page so the
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment