Varnish (software): Difference between revisions

Varnish
Developer(s)	Poul-Henning Kamp, Linpro, Varnish Software
Stable release	3.0.3 / August 20, 2012
Repository	github.com/varnishcache/varnish-cache ;
Written in	C
Operating system	Unix
Type	HTTP accelerator
License	BSD
Website	www.varnish-cache.org

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 15:42, 16 December 2012

Varnish is an HTTP accelerator designed for content-heavy dynamic web sites. In contrast to other HTTP accelerators, such as Squid, which began life as a client-side cache, or Apache and nginx, which are primarily origin servers, Varnish was designed as an HTTP accelerator. Varnish is focused exclusively on HTTP, unlike other proxy servers that often support FTP, SMTP and other network protocols.

History

The project was initiated by the online branch of the Norwegian tabloid newspaper Verdens Gang. The architect and lead developer is Danish independent consultant Poul-Henning Kamp (a well-known FreeBSD core developer), with management, infrastructure and additional development originally provided by the Norwegian Linux consulting company Linpro. The support, management and development of Varnish was later spun off into a separate company, Varnish Software.

Varnish is open source, available under a two-clause BSD license. Commercial support is available from Varnish Software, amongst others.

Version 1.0 of Varnish was released in 2006.^[1] Varnish 2.0 was released in 2008,^[2] and Varnish 3.0 was released in 2011.^[3]

Architecture

Varnish stores data in virtual memory and leaves the task of deciding what is stored in memory and what gets paged out to disk to the operating system. This helps avoid the situation where the operating system starts caching data while they are moved to disk by the application.

Furthermore, Varnish is heavily [[./Thread_(computer_science)|threaded]], with each client connection being handled by a separate worker thread. When the configured limit on the number of active worker threads is reached, incoming connections are placed in an overflow queue; when this queue reaches its configured limit incoming connections will be rejected.

The principal configuration mechanism is VCL (Varnish Configuration Language), a domain-specific language (DSL) used to write hooks which are called at critical points in the handling of each request. Most policy decisions are left to VCL code, making Varnish more configurable and adaptable than most other HTTP accelerators. When a VCL script is loaded, it is translated to C, compiled to a shared object by the system compiler, and linked directly into the accelerator.

A number of run-time parameters control things such as the maximum and minimum number of worker threads, various timeouts etc. A command-line management interface allows these parameters to be modified, and new VCL scripts to be compiled, loaded and activated, without restarting the accelerator.

In order to reduce the number of system calls in the fast path to a minimum, log data is stored in shared memory, and the task of filtering, formatting and writing log data to disk is delegated to a separate application.

Performance

While Varnish is designed to reduce contention between threads to a minimum, its authors claim^{[citation needed]} that its performance will only be as good as that of the system's pthreads implementation.

Additionally, a poor malloc implementation may add unnecessary contention and thereby limit performance, hence the general recommendation of running Varnish on Linux or Unix based environments.

Load balancing

Varnish supports load balancing using both a round robin and a random director, both with a per-backend weighting. Basic health-checking of backends is also available.^[4]

Other features

Varnish Cache also features:

Plugin support with Varnish Modules, also called VMODs^[5]
Support for Edge Side Includes including stitching together compressed ESI fragments
Gzip Compression and Uncompression
DNS, Random, Hashing and Client IP based Directors
Technology preview for HTTP Streaming Pass & Fetch
Experimental support for Persistent Storage, without LRU eviction
Saint and Grace mode

References

External links

Official development web site
Official commercial web site
Notes from the Architect
"You're Doing It Wrong", June 11, 2010 ACM Queue article by Varnish developer Poul-Henning Kamp describing the implementation of the LRU list.
Varnish in Layman's Terms

[1] "Making Catalyst Sites Shine with Varnish", Dec. 14, 2008

[2] "Varnish 2.0 released!", Jun. 16 2011

[3] ttps://www.varnish-cache.org/releases/varnish-cache-3.0.0

[4] ttp://www.varnish-cache.org/wiki/BackendPolling

[5] ttp://www.varnish-cache.org/vmods

[1]

[2]

[3]

[4]

[5]

@@ Line 25: / Line 25: @@
 Varnish stores data in [[virtual memory]] and leaves the task of deciding what is stored in memory and what gets paged out to disk to the [[operating system]]. This helps avoid the situation where the operating system starts caching data while they are moved to disk by the application.
-Furthermore, Varnish is heavily [[Thread (computer science)|threaded]], with each client connection being handled by a separate worker thread.  When the configured limit on the number of active worker threads is reached, incoming connections are placed in an overflow queue; when this queue reaches its configured limit will incoming connections be rejected.
+Furthermore, Varnish is heavily [[./Thread_(computer_science)|threaded]], with each client connection being handled by a separate worker thread.  When the configured limit on the number of active worker threads is reached, incoming connections are placed in an overflow queue; when this queue reaches its configured limit incoming connections will be rejected.
 The principal configuration mechanism is VCL (''Varnish Configuration Language''), a [[domain-specific language]] (DSL) used to write hooks which are called at critical points in the handling of each request.  Most policy decisions are left to VCL code, making Varnish more configurable and adaptable than most other HTTP accelerators.  When a VCL script is loaded, it is translated to [[C (programming language)|C]], compiled to a shared object by the system compiler, and linked directly into the accelerator.