Varnish

So we change it to 80:

#! /bin/sh  
...
VARNISH_PORT=80
...
VARNISH_CONFIG_FILE=/opt/bitnami/varnish/etc/varnish/default.vcl
...

backend default {
    .host = "127.0.0.1";
    .port = "80";
}      

And we change the port from 80 to the new Apache port, 81:

backend default {
    .host = "127.0.0.1";
    .port = "81";
}      

After restarting, Apache uncached should be available at port 81 and Varnish at 80 as revese proxy for Apache:

cd <installdir>
./ctlscript.sh restart

How to change the configuration file?

Varnish is installed with a default configuration file, agnostic to the web application being cached. Using this configuration file, although achieving high performance, could lead to some contents not properly refreshed in the cache so your users would get an outdated version of your site.

The solution is to use a particularized VCL configuration file. There are multiple sources on the Internet that provides customized configuration files for different applications. A good source is the Varnish examples page. In this example, we will change our default.vcl configuration file to a WordPress-specific one (you can find the source file here).

The file requires a little modification to register the port in which your Apache server will be running. This port can be read either from the Apache configuration, looking for the "Listen" directive (in <installdir>/apache2/conf/httpd.conf):

...
# Change this to Listen on specific IP addresses as shown below to 
# prevent Apache from glomming onto all bound IP addresses.
# 
#Listen 12.34.56.78:80
Listen 80
...

Or executing in a console:

$ egrep '^Listen ' <installdir>/apache2/conf/httpd.conf
Listen 80

With this value (80), we edit the dowloaded wordpres.vcl and look for the section below, usually at the top of the file :

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}      

And we change the port:

backend default {
    .host = "127.0.0.1";
    .port = "8180";
}            

In the case of the BitNami stacks, Varnish is installed in the same server as Apache so the .host can be configured as `127.0.0.1` but you could also use Varnish to cache a remote server. In that case you should also provide the host IP.

After performing this modification, we copy the file to the varnish directory:

cp /path/to/the/wordpress.vcl  <installdir>/varnish/etc/varnish/

And then change the varnish ctl scripts to load the appropriate file. To do that, we first ensure Varnish is stopped:

cd <installdir>
./ctlscript.sh stop varnish

And then edit the file `<installdir>/varnish/scripts/ctl.sh`  and change the `VARNISH_CONFIG_FILE` variable to point to the new file:

#! /bin/sh
...
VARNISH_CONFIG_FILE=/opt/bitnami/varnish/etc/varnish/wordpress.vcl
...

And now we restart Varnish (and apache if needed):

./ctlscript.sh start varnish
./ctlscript.sh start apache

How to check the performance gain using Varnish?

Although the real test will need real users interacting with your application, there are multiple solutions to perform rough load tests.  In the below graphics we used blitz.io, a service that provides a free test with one minute of duration from 250 concurrent users.

The selected application to test was WordPress Stack, running in an Amazon micro instance:

You can see how around 25 users the response time starts growing really fast, and how it start failing around 50 users, making the timeouts/sec rate continuously grow (the orange line). At that point the machine became unresponsive and we were forced to restart it so be careful if you plan to test this in your production environment.

Then we configured and started Varnish using the default configuration file and repeated the test:

In ths case, you can observe how the initial 25ms response time decreases below the 10ms when the cache if filled and keeps stable while the users keep growing. You can also observ we did not get any error or timeout in the process.

Although these results are really impressive, as we already mentioned, to make Varnish properly handle WordPress, we should use the wordpress.vcl file. The below test repeat the process using the WordPress-specific file:

As observer, it still produces great results, with a slightly bigger response time  (around 12ms in average) but it will improve how the cache is used.