In today's fast-paced digital landscape, web application performance is key to delivering seamless user experiences. Users expect fast-loading web pages and swift interactions. Any delays or sluggishness can lead to frustration, increased bounce rates, lost sales, and a tarnished reputation.
To ensure that your web application meets these expectations, you can leverage optimization technologies to enhance performance. Enter Varnish – a reliable HTTP accelerator that can revolutionize the speed and efficiency of your web application.
In this article, we will explore the power and potential of Varnish, guiding you through its key features, benefits, and use cases. We will share the exact steps to install, configure, and optimize it for maximum performance. Additionally, we will address security considerations and introduce some monitoring tools to ensure that Varnish remains robust and effective.
Varnish is a reverse proxy that speeds up websites by caching HTTP content. In a typical architecture, Varnish acts as an intermediary between clients and web servers. It stores and serves frequently accessed web resources from its local memory, resulting in reduced server load and faster response times.
Varnish is open-source, and available for different operating systems, including major Linux distributions, macOS, and Windows. Some of its key features are:
In addition to the obvious benefits of increased performance and speed, here are a few other reasons why you should use Varnish:
To understand how Varnish works, let’s explore its workflow:
HTTP optimization encompasses a set of techniques that can be used to improve website performance. Examples of optimization strategies include caching, reducing the size of images, CSS minification, and using a Content Delivery Network (CDN).
While optimizing the HTTP performance of your website, it’s important to consider the following factors:
Let’s look at a few reasons why HTTP optimization is pivotal for online success:
In this section, we will share the steps to get started with Varnish on an Ubuntu server. Let’s begin.
The list of available Varnish packages is available on the Packagecloud website. As of the time of writing, the latest stable version of Varnish is 7.3.0. According to the official Varnish website, the only three supported versions are 7.3.0, 7.2.1, and 6.0.11, as all other versions have reached end-of-life. Depending on your specific requirements, choose a Varnish version to install. We recommend installing 7.3.0.
Run the following command to get information about all the latest available packages:
sudo apt-get update
To fetch the right Varnish package for installation, we must configure the repository that contains the package. But first, run this command to install all the dependencies we must configure the Varnish package repository:
sudo apt-get install debian-archive-keyring curl gnupg apt-transport-https
This command is used to add the GPG key to our package manager:
curl -s -L https://packagecloud.io/varnishcache/varnish60lts/gpgkey | sudo apt-key add -
Finally, execute these commands to configure the Varnish package repository:
. /etc/os-release
sudo tee /etc/apt/sources.list.d/varnishcache_varnish60lts.list > /dev/null <<-EOF
deb https://packagecloud.io/varnishcache/varnish60lts/$ID/ $VERSION_CODENAME main
EOF
sudo tee /etc/apt/preferences.d/varnishcache > /dev/null <<-EOF
Package: varnish varnish-*
Pin: release o=packagecloud.io/varnishcache/*
Pin-Priority: 1000
EOF
Run the update command again so that information about the newly configured repository is also fetched.
sudo apt-get update
Finally, run this command to install the latest (7.3.0) version of Varnish
sudo apt-get install varnish
Now that Varnish is installed on our system, we’ll go through some steps to configure it.
Step # 1 – The systemd configuration
The systemd configuration file for Varnish is located at: /lib/systemd/system/varnish.service
You may tweak the settings in this file as per your needs. To do so, run the following command, which opens the file in the default editor:
sudo systemctl edit --full varnish
For instance, if you want to increase the maximum number of open file descriptors for Varnish, you can modify the LimitNOFILE parameter in the file, which defaults to 131072. You can also set the max size of the core file using the LimitCORE parameter, which defaults to infinity.
The ExecStart statement in the file includes the different command line options passed to the varnishd process at startup. You can pass your desired port, cache size, and any other options to Varnish by changing this command. For instance, we have changed the port to 80, and set the size of cache to 5 gigabytes. The ExecStart command is updated to:
ExecStart=/usr/sbin/varnishd \
-a :80 \
-a www.site24x7.jp,PROXY \
-p feature=+http2 \
-f /etc/varnish/default.vcl \
-s malloc,5g
Once you have made all the changes to the file, save it, and run the following command:
sudo systemctl daemon-reload
Step # 2 – Configuring Apache to run with Varnish
The next step is to configure your web server to run with Varnish. For this article, we will be using Apache, but you can configure any server that uses HTTP.
Step # 3 – Configuring your backends using VCL
The default VCL file is located at /etc/varnish/default.vcl. The default backend specification in the file uses the IP 127.0.0.1 and port 8080.
backend default {
.host = "127.0.0.1";
.port = "8080";
}
If you chose a different port in the last step, specify that here. You can also add more backends to your Varnish setup using the same syntax.
backend python {
.host = "127.0.0.1";
.port = "7000";
}
The above command will configure another backend for our Python-based web application.
Step # 4 – Restarting Apache and Varnish
Finally, we are ready to restart Apache and Varnish so that all the changes can be applied. Run the following command:
sudo systemctl restart apache2 varnish
Unlike most systems, Varnish doesn’t use configuration directives, and instead relies on VCL for configuration. Whether you want to implement an access control list, add health checks, use hashing for cached data, or serve content based on the user device, you can achieve it with VCL. Let’s look at a few tips and tricks to optimize Varnish configuration.
By defining specific rules in VCL, you can control which content should be cached and for how long. One approach is to create cache rules based on URL patterns. Varnish allows you to match URLs using regular expressions and apply specific caching directives accordingly. Let’s look at an example:
sub vcl_recv {
# Match URLs starting with "/articles/"
if (req.url ~ "^/articles/") {
# Set a longer cache Time to Live (TTL) for articles
set beresp.ttl = 1h;
}
# Match URLs ending with ".css" or ".js"
if (req.url ~ "\.(css|js)$") {
# Cache these static assets for a longer duration
set beresp.ttl = 7d;
}
}
In the above code snippet, we are setting a longer TTL for the articles on our website, as they are less frequently updated. We are also caching static assets for a longer duration.
Similarly, you can also configure cache rules based on specific request or response headers. Here's an example:
sub vcl_backend_response {
# Cache responses with a specific header value
if (beresp.http.X-Cacheable == "true") {
# Set a custom cache TTL for cacheable responses
set beresp.ttl = 1h;
}
}
In the above snippet, we update the TTL of a cache result if the response contains a particular header.
It’s important to have a cache invalidation strategy in place to ensure that users never get stale or outdated content. Varnish supports three different cache invalidation strategies:
HTTP purging: This method involves discarding an object from the cache. An example:
sub vcl_recv {
if (req.method == "PURGE") {
if (client.ip !~ purge_acl) {
return(synth(403, "Forbidden"));
}
# Extract the URL to be purged
set req.http.X-Purge-URL = regsub(req.url, "^[^:]*:[/]{2}", "");
return (purge);
}
}
In the above code snippet, we first check whether the request method is PURGE, then verify that the client IP is part of the purge ACL, then extract the URL using a regular expression, and finally purge the URL from the cache.
Bans: Another way to enforce cache invalidation is by banning certain content from being served by the cache. For example:
sub vcl_backend_response {
# Add cache tags to the response headers
set beresp.http.Cache-Tags = "category-123";
}
sub vcl_recv {
# Invalidate cache when specific cache tags are present in the request
if (req.http.Cache-Tags ~ "category-123") {
# Remove the associated content from the cache
ban("obj.http.Cache-Tags ~ category-123");
}
}
In the above code snippet, we are imposing a ban when a particular tag is part of the response headers.
Force a cache miss: To ensure that Varnish never caches an object, you can use the req.hash_always_miss parameter.
sub vcl_recv {
# Bypass cache for requests with a specific query parameter
if (req.url ~ "^/api" && req.url ~ "refresh=true") {
set req.hash_always_miss = true;
return (hash);
}
}
In the above code snippet, we set the req.hash_always_miss to true for all API requests that have a specific query parameter set to true.
Several parameters in Varnish can be adjusted to optimize performance based on your specific needs. Here are a few examples:
If you are using multiple backends, you can use VCL to implement logic to route requests based on factors such as request headers, URL patterns, or other conditions. Consider this example:
sub vcl_recv {
if (req.http.User-Agent ~ "Mobile") {
# Route mobile users to a specific backend server
set req.backend_hint = mobile_backend;
} else if (req.url ~ "^/auth/") {
# Route auth requests to a dedicated backend server
set req.backend_hint = auth_backend;
} else {
# Route all other requests to the default backend server
set req.backend_hint = default_backend;
}
}
In the above code snippet, we are routing mobile client requests to a dedicated mobile backend, authentication requests to the authentication backend, and all other requests to the default backend server.
Consider the following guidelines to ensure high availability:
Varnish offers several security controls to protect your web servers from cyberattacks.
Varnish is bundled with different tools for monitoring and reporting.
Varnish is a reliable HTTP cache that plays a pivotal role in enhancing the performance and scalability of web architectures. With its diverse feature set, customizable VCL configuration, and built-in security features, Varnish empowers developers to optimize their applications and safeguard their web servers from potential threats.
However, it's important to remember that Varnish is just one part of the equation. For optimal website performance, monitoring performance from the users’ perspective is crucial. This is where Site24x7 comes in.
Site24x7 offers comprehensive website performance monitoring solutions that allow you to track the performance of your web applications from various geographical locations. By combining the power of Varnish with the insights provided by Site24x7, you can guarantee optimal performance for your website.
Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 “Learn” portal. Get paid for your writing.
Apply Now