Varnish 1.1

Varnish is a high-performance HTTP accelerator designed for sites with large amounts of non-personalized dynamic content, such as online newspapers.

Here are some key features of "Varnish":

Pure HTTP accelerator
· Varnish will deliver cached documents received from your backend(s), and do this fast

Very fast
· Varnish is buildt for speed, and should out-perform any other Open Source HTTP accelerator.

Multiprocessor/core support
· Buildt with the future in mind, Varnish supports modern hardware technology.

64-bit computing support
· While it can run on a 32-bit platform, Varnish was buildt with 64-bit computing in mind.

Modern operatingsystem technology
· To be able to deliver content as efficient as possible Varnish takes in use the latest operatingsystem features like Kqueue/Epoll and Sendfile. Varnish is also IPv6 compatible.

Powerful configuration possibilities
· Varnish has a powerful configurationlanguage (VCL) which gives you endless possibilities and power over your content.

Runtime configuration deployment
· Changing of configurationfiles are done in runtime, no need to stop/ restart your service(s).

Protection of backend(s)
· Varnish is easily configured to not just stand around and see your backend(s) die if you are getting flooded with unwanted traffic. Give crawlers the content you feel they deserve. If your backend(s) should experience planned or unplanned downtime configure Varnish to never expire or fetch new content.

Ease of managment
· Your Varnish server(s) can be centrally controlled from a managment program for quick deployment of changes to your system. Different interfaces are available for those that dont like the commandline.

Central and flexible logging
· Logs are written to shared-memory, so logging is cheap. A centrally controlled logger program connects to the servers and collects these data so you can easily customize what, and how, you wanna logg to either display or file. This is done securely.

Realtime statistics
· As with logging, we provide you with a centrally controlled statistics collector to aggregate numbers from each server or present them individially. Again this is done in a securely manner.

Instant wildcard purging of documents
· Varnish will instantly stop delivery of any cached documents matching any regualar expression you give it, without wasting time traversing any structure or cached document.

Plugable storage backend(s)
· We give you memory, file or tar-file (Read-Only) backend out of the box, if you wanna store/read from another backend we leave you with an API.

Whats New in This Release:

varnishd

• Readability of the C source code generated from VCL code has been improved.

• Equality (==) and inequality (!=) operators have been implemented for IP
addresses (which previously could only be compared using ACLs).

• The address of the listening socket on which the client connection was
received is now available to VCL as the server.ip variable.

• Each objects hash key is now computed based on a string which is available
to VCL as req.hash. A VCL hook named vcl_hash has been added to allow VCL
scripts to control hash generation (for instance, whether or not to include
the value of the Host: header in the hash).

• The setup code for listening sockets has been modified to detect and handle
situations where a host name resolves to multiple IP addresses. It will now
attempt to bind to each IP address separately, and report a failure only if
none of them worked.

• Network or protocol errors that occur while retrieving an object from a
backend server now result in a synthetic error page being inserted into the
cache with a 30-second TTL. This should help avoid driving an overburdened
backend server into the ground by repeatedly requesting the same object.

• The child process will now drop root privileges immediately upon startup.
The user and group to use are specified with the user and group run-time
parameters, which default to nobody and nogroup, respectively. Other
changes have been made in an effort to increase the isolation between
parent and child, and reduce the impact of a compromise of the child
process.

• Objects which are received from the backend with a Vary: header are now
stored separately according to the values of the headers specified in
Vary:. This allows Varnish to correctly cache e.g. compressed and
uncompressed versions of the same object.

• Each Varnish instance now has a name, which by default is the host name of
the machine it runs on, but can be any string that would be valid as a
relative or absolute directory name. It is used to construct the name of a
directory in which the server state as well as all temporary files are
stored. This makes it possible to run multiple Varnish instances on the
same machine without conflict.

• When invoked with the -C option, varnishd will now not just translate the
VCL code to C, but also compile the C code and attempt to load the
resulting shared object.

• Attempts by VCL code to reference a variable outside its scope or to assign
a value to a read-only variable will now result in compile-time rather than
run-time errors.

• The new command-line option -F will make varnishd run in the foreground,
without enabling debugging.

• New VCL variables have been introduced to allow inspection and manipulation
of the request sent to the backend (bereq.request, bereq.url, bereq.proto
and bereq.http) and the response to the client (resp.proto, resp.status,
resp.response and resp.http).

• Statistics from the storage code (including the amount of data and free
space in the cache) are now available to varnishstat and other
statistics-gathering tools.

• Objects are now kept on an LRU list which is kept loosely up-to-date (to
within a few seconds). When cache runs out, the objects at the tail end of
the LRU list are discarded one by one until there is enough space for the
freshly requested object(s). A VCL hook, vcl_discard, is allowed to inspect
each object and determine its fate by returning either keep or discard.

• A new VCL hook, vcl_deliver, provides a chance to adjust the response
before it is sent to the client.

• A new management command, vcl.show, displays the VCL source code of any
loaded configuration.

• A new VCL variable, now, provides VCL scripts with the current time in
seconds since the epoch.

• A new VCL variable, obj.lastuse, reflects the time in seconds since the
object in question was last used.

• VCL scripts can now add an HTTP header (or modify the value of an existing
one) by assigning a value to the corresponding variable, and strip an HTTP
header by using the remove keyword.

• VCL scripts can now modify the HTTP status code of cached objects
(obj.status) and responses (resp.status)

• Numeric and other non-textual variables in VCL can now be assigned to
textual variables; they will be converted as needed.

• VCL scripts can now apply regular expression substitutions to textual
variables using the regsub function.

• A new management command, status, returns the state of the child.

• Varnish will now build and run on Mac OS X.

varnishadm

• This is a new utility which sends a single command to a Varnish servers
management port and prints the result to stdout, greatly simplifying the
use of the management port from scripts.

varnishhist

• The user interface has been greatly improved; the histogram will be
automatically rescaled and redrawn when the window size changes, and it is
updated regularly rather than at a rate dependent on the amount of log data
gathered. In addition, the name of the Varnish instance being watched is
displayed in the upper right corner.

varnishncsa

• In addition to client traffic, varnishncsa can now also process log data
from backend traffic.

• A bug that would cause varnishncsa to segfault when it encountered an empty
HTTP header in the log file has been fixed.

varnishreplay

• This new utility will attempt to recreate the HTTP traffic which resulted
in the raw Varnish log data which it is fed.

varnishstat

• Dont print lifetime averages when it doesnt make any sense—for instance,
there is no point in dividing the amount in bytes of free cache space by
the lifetime in seconds of the varnishd process.

• The user interface has been greatly improved; varnishstat will no longer
print more than fits in the terminal, and will respond correctly to window
resize events. The output produced in one-shot mode has been modified to
include symbolic names for each entry. In addition, the name of the Varnish
instance being watched is displayed in the upper right corner in curses
mode.

varnishtop

• The user interface has been greatly improved; varnishtop will now respond
correctly to window resize events, and one-shot mode (-1) actually works.
In addition, the name of the Varnish instance being watched is displayed in
the upper right corner in curses mode.