Varnish (software): Difference between revisions
→See also: +wikilinks |
No edit summary |
||
Line 5: | Line 5: | ||
| caption = |
| caption = |
||
| developer = [[Poul-Henning Kamp]], [[Linpro]], [[Varnish Software]] |
| developer = [[Poul-Henning Kamp]], [[Linpro]], [[Varnish Software]] |
||
| latest release version = 2.1. |
| latest release version = 2.1.3 |
||
| latest release date = {{release date|2010| |
| latest release date = {{release date|2010|07|28}} |
||
| programming language = [[C (programming language)|C]] |
| programming language = [[C (programming language)|C]] |
||
| operating system = [[Unix]] |
| operating system = [[Unix]] |
Revision as of 00:19, 10 October 2010
Developer(s) | Poul-Henning Kamp, Linpro, Varnish Software |
---|---|
Stable release | 2.1.3
/ July 28, 2010 |
Repository | |
Written in | C |
Operating system | Unix |
Type | HTTP accelerator |
License | BSD |
Website | http://varnish-cache.org/ |
Varnish is an HTTP accelerator designed for content-heavy dynamic web sites. In contrast to other HTTP accelerators, many of which began life as client-side proxies or origin servers, Varnish was designed from the ground up as an HTTP accelerator.
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, 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]
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 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; only when this queue reaches its configured limit will incoming connections 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 far 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 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.
When the requested document is in cache, response time is typically measured in microseconds.[citation needed] This is significantly better than most HTTP servers,[citation needed] so even sites consisting mostly of static content will benefit from Varnish.
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.[2]
See also
Overview & Discussions
- Web accelerator which discusses host-based HTTP acceleration
- Proxy server which discusses client-side proxies
- Reverse proxy which discusses origin-side proxies
- Comparison of web servers
- Comparison of lightweight web servers
- Internet Cache Protocol
Proxy-Servers
- Apache HTTP Server
- lighttpd - open-source web server, optimized for speed-critical environments
- Nginx - lightweight, high-performance web server, reverse proxy and e-mail proxy (IMAP/POP3)
- Polipo - lightweight pipelining, multiplexing proxy server and daemon for a small number of users
- Pound reverse proxy
- Privoxy - privacy enhancing proxy
- Squid cache - a proxy server and web cache daemon
- Ziproxy - lightweight forwarding, non-caching, HTTP proxy for traffic optimization
References
External links
- Official development web site
- Official commercial web site
- "You're Doing It Wrong", June 11, 2010 ACM Queue article by Varnish developer Poul-Henning Kamp describing the implementation of the LRU list.