Commit e90fce30 authored by Lasse Karstensen's avatar Lasse Karstensen

Be consistent with capitalisation and whitepace.

parent c93b3eeb
......@@ -31,9 +31,9 @@ Varnish is split over two processes, the manager and the child. The child
does all the work, and the manager hangs around to resurect it, if it
crashes.
Therefore, the first thing to do if you see a varnish crash, is to examine
Therefore, the first thing to do if you see a Varnish crash, is to examine
your syslogs, to see if it has happened before. (One site is rumoured
to have had varnish restarting every 10 minutes and *still* provide better
to have had Varnish restarting every 10 minutes and *still* provide better
service than their CMS system.)
When it crashes, if at all possible, Varnish will spew out a crash dump
......@@ -116,7 +116,7 @@ able to figure that out.
If one or more threads are spinning, use ``strace`` or ``ktrace`` or ``truss``
(or whatever else your OS provides) to get a trace of which system calls
the varnish process issues. Be aware that this may generate a lot
the Varnish process issues. Be aware that this may generate a lot
of very repetitive data, usually one second worth is more than enough.
Also, run ``varnishlog`` for a second, and collect the output
......
......@@ -26,7 +26,7 @@ performance.
If you are running on 64bit OpenVZ (or Parallels VPS), you must reduce
the maximum stack size before starting Varnish.
The default allocates to much memory per thread, which will make varnish fail
The default allocates to much memory per thread, which will make Varnish fail
as soon as the number of threads (traffic) increases.
Reduce the maximum stack size by running::
......
......@@ -8,12 +8,12 @@ In order for you to install Varnish you must have the following:
- Linux
- FreeBSD
- Solaris (x86 only)
* root access to said system
* root access to said system.
Varnish can be installed on other UNIX systems as well, but it is not
tested particularly well on these plattforms. Varnish is, from time to
time, said to work on:
tested particularly well on these platforms. Varnish is, from time to
time, said to work on:
* 32 bit versions of the before-mentioned systems.
* OS X
......
=======
varnish
=======
===========
Varnish CLI
===========
------------------------------
Varnish Command Line Interface
......@@ -142,7 +142,7 @@ ping [timestamp]
Ping the Varnish cache process, keeping the connection alive.
quit
Close the connection to the varnish admin port.
Close the connection to the Varnish admin port.
start
Start the Varnish cache process if it is not already running.
......@@ -214,7 +214,7 @@ code and length field always is exactly 13 characters long, including
the NL character.
For your reference the sourcefile lib/libvarnish/cli_common.h contains
the functions varnish code uses to read and write CLI response.
the functions Varnish code uses to read and write CLI response.
.. _ref_psk_auth:
......@@ -318,9 +318,9 @@ SEE ALSO
HISTORY
=======
The varnish manual page was written by Per Buer in 2011. Some of the
The Varnish manual page was written by Per Buer in 2011. Some of the
text was taken from the Varnish Cache wiki, the varnishd(7) man page
or the varnish source code.
or the Varnish source code.
COPYRIGHT
=========
......@@ -328,4 +328,4 @@ COPYRIGHT
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2011 Varnish Software AS
* Copyright (c) 2011-2014 Varnish Software AS
......@@ -3,7 +3,7 @@ varnishadm
==========
----------------------------------
Control a running varnish instance
Control a running Varnish instance
----------------------------------
:Author: Cecilie Fritzvold
......@@ -90,4 +90,4 @@ COPYRIGHT
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2007-2011 Varnish Software AS
* Copyright (c) 2007-2014 Varnish Software AS
......@@ -70,7 +70,7 @@ OPTIONS
Specifies the hash algorithm. See Hash Algorithms for a list of supported algorithms.
-i identity
Specify the identity of the varnish server. This can be accessed using server.identity
Specify the identity of the Varnish server. This can be accessed using server.identity
from VCL
-l shmlogsize
......
......@@ -90,4 +90,4 @@ This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2006 Verdens Gang AS
* Copyright (c) 2006-2011 Varnish Software AS
* Copyright (c) 2006-2014 Varnish Software AS
......@@ -20,14 +20,14 @@ varnishreplay [-D] -a address:port -r file
DESCRIPTION
===========
The varnishreplay utility parses varnish logs and attempts to
reproduce the traffic. It is typcally used to *warm* up caches or
The varnishreplay utility parses Varnish logs and attempts to
reproduce the traffic. It is typically used to *warm* up caches or
various forms of testing.
The following options are available:
-a backend Send the traffic over tcp to this server, specified by an
address and a port. This option is
-a backend Send the traffic over tcp to this server, specified by an
address and a port. This option is
mandatory. Only IPV4 is supported at this time.
-D Turn on debugging mode.
......@@ -54,4 +54,4 @@ COPYRIGHT
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2007-2010 Varnish Software AS
* Copyright (c) 2007-2014 Varnish Software AS
......@@ -125,4 +125,4 @@ This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2006 Verdens Gang AS
* Copyright (c) 2006-2011 Varnish Software AS
* Copyright (c) 2006-2014 Varnish Software AS
......@@ -109,7 +109,7 @@ An example::
} -run
When run, the above script will simulate a server (s1) that expects two
different requests. It will start a varnish server (v1) and add the backend
different requests. It will start a Varnish server (v1) and add the backend
definition to the VCL specified (-vcl+backend). Finally it starts the
c1-client, which is a single client sending two requests.
......
......@@ -467,7 +467,7 @@ vcl_pass
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_hash
......@@ -497,7 +497,7 @@ vcl_hit
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_miss
......@@ -546,7 +546,7 @@ vcl_fetch
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_deliver
......@@ -560,7 +560,7 @@ vcl_deliver
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_error
......@@ -575,7 +575,7 @@ vcl_error
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_fini
......@@ -755,7 +755,7 @@ other words, they are available in vcl_fetch:
beresp.do_stream
Deliver the object to the client directly without fetching the whole
object into varnish. If this request is pass'ed it will not be
object into Varnish. If this request is pass'ed it will not be
stored in memory. As of Varnish Cache 3.0 the object will marked as busy
as it is delivered so only client can access the object.
......@@ -883,7 +883,7 @@ Grace and saint mode
If the backend takes a long time to generate an object there is a risk
of a thread pile up. In order to prevent this you can enable *grace*.
This allows varnish to serve an expired version of the object while a
This allows Varnish to serve an expired version of the object while a
fresh object is being generated by the backend.
The following vcl code will make Varnish serve expired objects. All
......@@ -1035,4 +1035,4 @@ This document is licensed under the same license as Varnish
itself. See LICENSE for details.
* Copyright (c) 2006 Verdens Gang AS
* Copyright (c) 2006-2011 Varnish Software AS
* Copyright (c) 2006-2014 Varnish Software AS
......@@ -25,9 +25,9 @@ function shown above. The full contents of the "std" module is
documented in vmod_std(7).
This part of the manual is about how you go about writing your own
VMOD, how the language interface between C and VCC works, where you
VMOD, how the language interface between C and VCC works, where you
can find contributed VMODs etc. This explanation will use the "std"
VMOD as example, having a varnish source tree handy may be a good
VMOD as example, having a Varnish source tree handy may be a good
idea.
VMOD Directory
......@@ -35,7 +35,8 @@ VMOD Directory
The VMOD directory is an up-to-date compilation of maintained
extensions written for Varnish Cache:
https://www.varnish-cache.org/vmods
https://www.varnish-cache.org/vmods
The vmod.vcc file
=================
......@@ -47,11 +48,11 @@ data structures that does all the hard work.
The std VMODs vmod.vcc file looks somewhat like this::
Module std
Init init_function
Function STRING toupper(PRIV_CALL, STRING_LIST)
Function STRING tolower(PRIV_VCL, STRING_LIST)
Function VOID set_ip_tos(INT)
$Module std
$Init init_function
$Function STRING toupper(PRIV_CALL, STRING_LIST)
$Function STRING tolower(PRIV_VCL, STRING_LIST)
$Function VOID set_ip_tos(INT)
The first line gives the name of the module, nothing special there.
......
......@@ -153,8 +153,8 @@ Description
fails, *fallback* will be returned.
Example
if (std.ip(req.http.X-forwarded-for, "0.0.0.0") ~ my_acl) { ... }
SEE ALSO
========
......@@ -174,4 +174,4 @@ COPYRIGHT
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
* Copyright (c) 2011 Varnish Software
* Copyright (c) 2011-2014 Varnish Software
......@@ -7,7 +7,7 @@ Varnish has a concept of "backend" or "origin" servers. A backend
server is the server providing the content Varnish will accelerate.
Our first task is to tell Varnish where it can find its content. Start
your favorite text editor and open the varnish default configuration
your favorite text editor and open the Varnish default configuration
file. If you installed from source this is
/usr/local/etc/varnish/default.vcl, if you installed from a package it
is probably /etc/varnish/default.vcl.
......@@ -21,7 +21,7 @@ the configuration that looks like this:::
}
This means we set up a backend in Varnish that fetches content from
the host www.varnish-cache.org on port 80.
the host www.varnish-cache.org on port 80.
Since you probably don't want to be mirroring varnish-cache.org we
need to get Varnish to fetch content from your own origin
......
......@@ -24,7 +24,7 @@ You will most likely want to set this to ":80" which is the Well
Known Port for HTTP.
You can specify multiple addresses separated by a comma, and you
can use numeric or host/service names if you like, varnish will try
can use numeric or host/service names if you like, Varnish will try
to open and service as many of them as possible, but if none of them
can be opened, varnishd will not start.
......@@ -38,7 +38,7 @@ Here are some examples::
If your webserver runs on the same computer, you will have to move
it to another port number first.
-f *VCL-file* or -b *backend*
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......
......@@ -33,7 +33,7 @@ Interface, which can be used manually, from scripts or programs.
The CLI offers almost full control of what Varnish actually does
to your HTTP traffic, and we have gone to great lengths to ensure
that you should not need to restart the varnish processes, unless
that you should not need to restart the Varnish processes, unless
you need to change something very fundamental.
The CLI can be safely accessed remotely, using a simple and flexible
......
......@@ -18,7 +18,7 @@ is logging. Varnishlog gives you the raw logs, everything that is
written to the logs. There are other clients as well, we'll show you
these later.
In the terminal window you started varnish now type *varnishlog* and
In the terminal window you started Varnish now type *varnishlog* and
press enter.
You'll see lines like these scrolling slowly by.::
......@@ -27,7 +27,7 @@ You'll see lines like these scrolling slowly by.::
0 CLI - Wr 200 PONG 1273698726 1.0
These is the Varnish master process checking up on the caching process
to see that everything is OK.
to see that everything is OK.
Now go to the browser and reload the page displaying your web
app. You'll see lines like these.::
......@@ -55,10 +55,10 @@ Now, you can filter quite a bit with varnishlog. The basic option you
want to know are:
-b
Only show log lines from traffic going between Varnish and the backend
Only show log lines from traffic going between Varnish and the backend
servers. This will be useful when we want to optimize cache hit rates.
-c
-c
Same as -b but for client side traffic.
-m tag:regex
......
......@@ -4,7 +4,7 @@
Statistics
----------
Now that your varnish is up and running let's have a look at how it is
Now that your Varnish is up and running let's have a look at how it is
doing. There are several tools that can help.
varnishtop
......@@ -48,10 +48,10 @@ varnishstat
Varnish has lots of counters. We count misses, hits, information about
the storage, threads created, deleted objects. Just about
everything. varnishstat will dump these counters. This is useful when
tuning varnish.
tuning Varnish.
There are programs that can poll varnishstat regularly and make nice
graphs of these counters. One such program is Munin. Munin can be
found at http://munin-monitoring.org/ . There is a plugin for munin in
the varnish source code.
the Varnish source code.
......@@ -11,7 +11,7 @@ bad for business.
The solution is to notify Varnish when there is fresh content
available. This can be done through three mechanisms. HTTP purging,
banning and forced cache misses. First, let me explain the HTTP purges.
banning and forced cache misses. First, let me explain the HTTP purges.
HTTP Purges
......@@ -31,7 +31,7 @@ following VCL in place::
"localhost";
"192.168.55.0"/24;
}
sub vcl_recv {
# allow PURGE from localhost and 192.168.55...
......@@ -42,14 +42,14 @@ following VCL in place::
return (lookup);
}
}
sub vcl_hit {
if (req.method == "PURGE") {
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.method == "PURGE") {
purge;
......@@ -93,7 +93,7 @@ the following command::
Quite powerful, really.
Bans are checked when we hit an object in the cache, but before we
deliver it. *An object is only checked against newer bans*.
deliver it. *An object is only checked against newer bans*.
Bans that only match against obj.* are also processed by a background
worker threads called the *ban lurker*. The ban lurker will walk the
......@@ -168,7 +168,7 @@ Forcing a cache miss
The final way to invalidate an object is a method that allows you to
refresh an object by forcing a hash miss for a single request. If you set
req.hash_always_miss to true, varnish will miss the current object in the
req.hash_always_miss to true, Varnish will miss the current object in the
cache, thus forcing a fetch from the backend. This can in turn add the
freshly fetched object to the cache, thus overriding the current one. The
old object will stay in the cache until ttl expires or it is evicted by
......
......@@ -79,9 +79,9 @@ only allow specific CLI commands.
It is also possible to configure varnishd for "reverse mode", using
the '-M' argument. In that case varnishd will attempt to open a
TCP connection to the specified address, and initiate a CLI connection
to your central varnish management facility.
to your central Varnish management facility.
The connection is also in this case without secrecy, but
The connection is also in this case without secrecy, but
the remote end must still satisfy -S/PSK authentication.
Finally, if you run varnishd with the '-d' option, you get a CLI
......@@ -217,4 +217,4 @@ If you have "administrative" HTTP requests, for instance PURGE
requests, we strongly recommend that you restrict them to trusted
IP numbers/nets using VCL's Access Control Lists.
(XXX: missing ref to ACL)
.. (XXX: missing ref to ACL)
......@@ -19,7 +19,7 @@ task. A few things to consider:
Be aware that every object that is stored also carries overhead that
is kept outside the actually storage area. So, even if you specify -s
malloc,16G varnish might actually use **double** that. Varnish has a
malloc,16G Varnish might actually use **double** that. Varnish has a
overhead of about 1k per object. So, if you have lots of small objects
in your cache the overhead might be significant.
......@@ -5,7 +5,7 @@ Troubleshooting Varnish
Sometimes Varnish misbehaves. In order for you to understand whats
going on there are a couple of places you can check. varnishlog,
/var/log/syslog, /var/log/messages are all places where varnish might
/var/log/syslog, /var/log/messages are all places where Varnish might
leave clues of whats going on. This section will guide you through
basic troubleshooting in Varnish.
......@@ -19,7 +19,7 @@ permissions on /dev/null to other processes blocking the ports.
Starting Varnish in debug mode to see what is going on.
Try to start varnish by::
Try to start Varnish by::
# varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1: 2000 -a 0.0.0.0:8080 -d
......@@ -31,7 +31,7 @@ listening on its port.::
storage_malloc: max size 1024 MB.
Using old SHMFILE
Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit
200 193
200 193
-----------------------------
Varnish Cache CLI.
-----------------------------
......@@ -45,7 +45,7 @@ instruct the master process to start the cache by issuing "start".::
start
bind(): Address already in use
300 22
300 22
Could not open sockets
And here we have our problem. Something else is bound to the HTTP port
......
......@@ -29,7 +29,7 @@ connect to port 8080 on localhost (127.0.0.1).
Varnish can have several backends defined and can you can even join
several backends together into clusters of backends for load balancing
purposes.
purposes.
Multiple backends
......@@ -72,7 +72,7 @@ It's quite simple, really. Lets stop and think about this for a
moment. As you can see you can define how you choose backends based on
really arbitrary data. You want to send mobile devices to a different
backend? No problem. if (req.User-agent ~ /mobile/) .. should do the
trick.
trick.
Backends and virtual hosts in Varnish
......@@ -104,7 +104,7 @@ more tight, maybe relying on the == operator in stead, like this:::
if (req.http.host == "foo.com" or req.http.host == "www.foo.com") {
set req.backend = foo;
}
}
}
.. _users-guide-advanced_backend_servers-directors:
......@@ -181,7 +181,7 @@ Whats new here is the probe. Varnish will check the health of each
backend with a probe. The options are
url
What URL should varnish request.
What URL should Varnish request.
interval
How often should we poll
......@@ -193,10 +193,10 @@ window
Varnish will maintain a *sliding window* of the results. Here the
window has five checks.
threshold
threshold
How many of the .window last polls must be good for the backend to be declared healthy.
initial
initial
How many of the of the probes a good when Varnish starts - defaults
to the same amount as the threshold.
......@@ -206,11 +206,11 @@ Now we define the director.::
{
.backend = server1;
}
# server2
# server2
{
.backend = server2;
}
}
You use this director just as you would use any other director or
......
......@@ -23,20 +23,20 @@ vcl_recv
been received and parsed. Its purpose is to decide whether or not
to serve the request, how to do it, and, if applicable, which backend
to use.
The vcl_recv subroutine may terminate with calling ``return()`` on one of
the following keywords:
error code [reason]
Return the specified error code to the client and abandon the request.
pass
pass
Switch to pass mode. Control will eventually pass to vcl_pass.
pipe
pipe
Switch to pipe mode. Control will eventually pass to vcl_pipe.
lookup
lookup
Look up the requested object in the cache. Control will
eventually pass to vcl_hit or vcl_miss, depending on whether the
object is in the cache. The ``bereq.method`` value will be set
......@@ -50,7 +50,7 @@ vcl_pipe
on to the backend, and any further data from either client or
backend is passed on unaltered until either end closes the
connection.
The vcl_pipe subroutine may terminate with calling return() with one of
the following keywords:
......@@ -67,10 +67,10 @@ vcl_pass
on to the backend, and the backend's response is passed on to the
client, but is not entered into the cache. Subsequent requests
submitted over the same client connection are handled normally.
The vcl_pass subroutine may terminate with calling return() with one
of the following keywords:
error code [reason]
Return the specified error code to the client and abandon the request.
......@@ -78,8 +78,8 @@ vcl_pass
Proceed with pass mode.
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_miss
......@@ -88,7 +88,7 @@ vcl_miss
Called after a cache lookup if the requested document was not found in
the cache. Its purpose is to decide whether or not to attempt to
retrieve the document from the backend, and which backend to use.
The vcl_miss subroutine may terminate with calling return() with one
of the following keywords:
......@@ -106,7 +106,7 @@ vcl_fetch
~~~~~~~~~
Called after a document has been successfully retrieved from the backend.
The vcl_fetch subroutine may terminate with calling return() with one
of the following keywords:
......@@ -117,7 +117,7 @@ of the following keywords:
error code [reason]
Return the specified error code to the client and abandon the request.
hit_for_pass
hit_for_pass
Pass in fetch. Passes the object without caching it. This will
create a so-called hit_for_pass object which has the side effect
that the decision not to cache will be cached. This is to allow
......@@ -131,15 +131,15 @@ of the following keywords:
object.
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_deliver
~~~~~~~~~~~
Called before a cached object is delivered to the client.
The vcl_deliver subroutine may terminate with one of the following
keywords:
......@@ -147,25 +147,25 @@ keywords:
Deliver the object to the client.
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_error
~~~~~~~~~
Called when we hit an error, either explicitly or implicitly due to
Called when we hit an error, either explicitly or implicitly due to
backend or internal errors.
The vcl_error subroutine may terminate by calling return with one of
the following keywords:
deliver
Deliver the error object to the client.
restart
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* varnish emits a guru meditation
Restart the transaction. Increases the restart counter. If the number
of restarts is higher than *max_restarts* Varnish emits a guru meditation
error.
vcl_fini
......
......@@ -11,7 +11,7 @@ Much of the VCL syntax has changed in Varnish 4. We've tried to compile a list o
Version statement
~~~~~~~~~~~~~~~~~
To make sure that people have upgraded their VCL to the current version, varnish now requires the first line of VCL to indicate the VCL version number::
To make sure that people have upgraded their VCL to the current version, Varnish now requires the first line of VCL to indicate the VCL version number::
vcl 4.0;
......@@ -30,7 +30,7 @@ Since the client director was already a special case of the hash director, it ha
h.add_backend(b1, 1);
h.add_backend(b2, 1);
}
sub vcl_recv {
set req.backend = h.backend(client.ip);
}
......
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