Varnish Configuration

Varnish Configuration

1 Introduction

This document is an overview of Varnish configuration for eXo SEA Portal. It is organized as follows:

• Section one gives an introduction to Varnish software (version 1.1.2)
• Section two explains how to install it, we are using Linux kernel version 2.6.27.
• The third section gives a brief description of Varnish configuration files for eXo Portal
• Whereas the last one discusses some of the practical issues encountered during the deployment of Varnish, the last section analyzes the speed gain by Varnish.

2 Overview

Varnish is a HTTP/web accelerator, it was written from the beginning to be a high-performance open source reverse proxy caching implementation. Varnish, like other caching reverse HTTP proxy implementations, is most frequently used to alleviate/reduce origin web servers of undue load, giving you the ability to handle a higher number of concurrent hits.

Nowadays, more and more web sites present dynamic web pages consisting of a number of different elements. Combining these elements is both time consuming and CPU intensive. The bad news is that the same process is repeated for every individual user, even when the content is identical. Fortunately in such a case a solution like Varnish can help to improve web server performance. How can Varnish accomplish this? Varnish temporarily stores the most frequently requested pages in its cache. It is more effective to present these pages from the Varnish cache. Therefore, users are offered an improved service, and Content/Document Management System server requirements are reduced.

Why are we using Varnish? In contrast with other HTTP accelerators, many of which began life as client-side proxies or origin servers, Varnish was designed from the scratch as an accelerator for incoming traffic. In addition, Varnish via his DSL (Domain Specific Language) is very flexible. In fact, this way, it provides users not only with a means of modifying and rewriting client requests or in certain cases server responses. But Varnish also enable the user to load multiple configurations concurrently. So users can instantaneously switch from one VCL (Varnish Configuration Language) to another. It is not all, Varnish TTL (Time to Live) parameter enables users to decide how long an object should be cached.

3 Installation of Varnish

3.1 Prerequisite

Before building Varnish, make sure that the following tools are installed :

• GCC compiler
• A POSIX-compatible make
• GNU autotools (automake, autoconf, libtool, ncurses)

3.2 Installation

If you are using a system with a graphical user interface, installation of Varnish 1.1.2 is quite easy via synaptic package manager. If not, you can run in a terminal by the following command to install Varnish on your computer:

sudo apt-get install varnish.

You can also install Varnish from source, see the following web site for more information:

http://varnish.projects.linpro.no.

3.3 Varnish configuration for eXo Portal

Varnish uses Varnish Configuration Language (VCL). The VCL language is a small domain-specific language designed to be used to define request handling and document caching policies for the Varnish HTTP accelerator. When a new configuration is loaded, the varnished management process translates the VCL code to C and compiles it to a shared object which is then dynamically linked into the server process.

Installation of Varnish automatically create two files named default.vcl and varnish in the repositories /etc/varnish/ and /etc/default respectively. One is VCL and another one contains values that will be passed as parameters to varnished. We will not make use of the first one, that is default.vcl. Create a new file named vcl.conf in /etc/varnish with the following contents:

Backend declaration, here we need to specify the web server host name and the listening http port.

backend default {
        .host = "127.0.0.1";
        .port = "8080";
}
#
## Called when a client request is received
#
sub vcl_recv {
        if (req.url ~ "^/$") {
        set req.url = regsub(req.url,"^/$","/portal");
        set req.http.Accept-Language = "vi";
        }
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        if (req.request != "GET" && req.request != "HEAD") {
                pipe;
        }
        if (req.http.Expect) {
                pipe;
        }
        if (req.request == "GET" && req.url ~ "\.(jpg|jpeg|gif|ico|tiff|tif|svg|css|js|html)$") {
            set req.url = regsub(req.url, "\?*", "");
             unset req.http.cookie;
	  unset req.http.authenticate;
             lookup;
        }
       if (req.http.Authenticate || req.http.Authorization) {
             pass;
        }
        if (req.http.Cache-Control ~ "no-cache") {
               set req.http.Cache-Control = regsub(req.http.Cache-Control, "no-cache", "set-cookie2");
        }
        # force lookup even when cookies are present
        if (req.request == "GET" && req.http.cookie) {
                lookup;
        }
        lookup;
}

In order to specify the default language for each web site, that is Vietnamese (vi) for vnwebsite and English (en) for enwebsite; the following statement set req.http.Accept-Language = "language code" is useful.

#
## Called when entering pipe mode
#
sub vcl_pipe {
        pipe;
}
#
## Called when entering pass mode
#
sub vcl_pass {
        pass;
}
#
## Called when the requested object was found in the cache
#
sub vcl_hit {
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        deliver;
}
## Called when the requested object has been retrieved from the
## backend, or the request to the backend has failed
sub vcl_fetch {
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        if (req.http.Cache-Control ~ "no-cache") {
               set req.http.Cache-Control = regsub(req.http.Cache-Control, "no-cache", "set-cookie2");
        }
        if(obj.cacheable){
                unset req.http.Set-Cookie;
	     set obj.http.Cache-Control = "no-cache";
                unset obj.http.Etag;
                if(obj.ttl < 7d){
                        set obj.ttl = 7d;
                }
                deliver;
        }
        deliver;
}

If the cookie is intended for use by a single user, the Set-Cookie2 header should not be cached. A Set-Cookie2 header that is intended to be shared by multiple users may be cached.

Remark: Since Etag (entity tag) in an HTTP response header that may be returned by an HTTP/1.1 compliant web server is used by the user-agent to determine change in content at a given URL. It is removed in order to instruct the user-agent that there is no change in content of cacheable objects. In fact, when a new HTTP response contains the same ETag as an older HTTP response, the client can conclude that the content is the same without further downloading.

## Called before a cached object is delivered to the client
sub vcl_deliver {
        deliver;
}
## Called when an object nears its expiry time
sub vcl_timeout {
        discard;
}
## Called when an object is about to be discarded
sub vcl_discard {
    discard;
}

This configuration tells Varnish to always cache all cacheable objects and don't invalidate them for at least one week.

Then modify the file /etc/default/varnish and make yourself sure that its content is not too different to this one, particularly the DAEMON_OPTS part. Note that we are using the advanced configuration, that is alternative 3.

# Configuration file for varnish
#
# /etc/init.d/varnish expects the variable $DAEMON_OPTS to be set from this
# shell script fragment.
#
# Maximum number of open files (for ulimit -n)
NFILES=131072
# Default varnish instance name is the local nodename.  Can be overridden with
# the -n switch, to have more instances on a single server.
INSTANCE=$(uname -n)
## Alternative 3, Advanced configuration
## We choose advance configuration
#
# See varnishd(1) for more information.
#
# # Main configuration file. You probably want to change it :)
VARNISH_VCL_CONF=/etc/varnish/default.vcl
#
# # Default address and port to bind to
# # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
# # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
VARNISH_LISTEN_ADDRESS=0.0.0.0
VARNISH_LISTEN_PORT=80
#
# # Telnet admin interface listen address and port
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
#
# # The minimum number of worker threads to start
VARNISH_MIN_THREADS=1
#
# # The Maximum number of worker threads to start
VARNISH_MAX_THREADS=2048
#
# # Idle timeout for worker threads
VARNISH_THREAD_TIMEOUT=120
#
# # Cache file location
VARNISH_STORAGE_FILE=/var/lib/varnish/$INSTANCE/varnish_storage.bin
#
# # Cache file size: in bytes, optionally using k / M / G / T suffix,
# # or in percentage of available disk space using the % suffix.
VARNISH_STORAGE_SIZE=5G
#
# # Backend storage specification
VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
#
# # Default TTL used when the backend does not specify one
VARNISH_TTL=7d
#
# # DAEMON_OPTS is used by the init script.  If you add or remove options, make
# # sure you update this section, too.
DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
              -f ${VARNISH_VCL_CONF} \
              -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
              -t ${VARNISH_TTL} \
	-w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
              -s ${VARNISH_STORAGE}"

4 How to launch Varnish?

Launch varnish service by using this command : sudo service varnish restart.

After launching Varnish service you should load your configuration file /etc/varnish/vcl.conf. To do this, follow this steps :

1. telnet (ip-of-server) (port) where (ip-of-server)=VARNISH_ADMIN_LISTEN_ADDRESS and (port)=VARNISH_ADMIN_LISTEN_PORT.
2. vcl.load myConfig /etc/varnish/vcl.conf.
3. vcl.use myConf.
4. start.

5 How fast is Varnish?

When using an HTTP accelerator, it is important to know whether our web server performance has improved or not. Thus, this section shows the performance gained by the use of Varnish.

5.1 Varnish testbed configuration

Our Varnish testbed consists of a desktop PC acting as a web server (WS), and 10 PC-based Linux acting as clients stations. The system hardware configuration is summarized in the following table. All machines except the WS use a Linux 2.6.27 kernel. The user-agent used on client stations is wget

The following table is the testbed summary:

It is well known that performance of a software like varnish depends on part on the communication link between server host and client stations. So, without loss of generality, we assume that our wireless connection is fair.

5.2 Varnish analyzes method

In other to evaluate Vanish performance, we first access all pages of our web site through Varnish to ensure that all cacheable objects can be found in Varnish cache. It takes in average 6.9s. Then we simultaneously send 100 download requests from each of our 2 client stations to the web server using wget user-agent through Varnish. After this operation, we evaluate the average time required by each client station to perform a download request. The same process is done without using Varnish. We then compare the obtained results.

5.3 Varnish performance analyzes

This part discuss about Varnish performance in term of time of response. That is the time that a given client should wait to get the requested object (or the server response). In this case the requested object is our entire web site. The collected measurements are summarized in the below table:

Remark: All times above are in second, these times include the time needed by the client to connect to the server.

Measurements listed above obviously shows that our web server performance are considerably improved by the use of Varnish software. In average per user request, we gain from Varnish 24 (twenty-four) seconds. That is using Varnish, user requests are at least 10 times faster than previously (without Varnish).