What it is, Where does it come from? What is it used for?

Varnish Cache is an HTTP accelerator. It's designed for content-heavy and dynamic web sites as well as APIs. Varnish focuses exclusively on HTTP,  other proxy servers that often support FTP, SMTP as well as other network protocols. Varnish Cache is really fast.

Poul-Henning Kamp and Redpill-Linpro are the creators of Varnish Software. The lead developer and architect are Danish independent consultants, Poul-Henning Kamp is a well-known FreeBSD developer, with management, infrastructure, and additional development originally provided by the Norwegian Linux consulting company Linpro.

Varnish was written in C.

Other Web Accelerators:

There are a lot of other web accelerators out there namely

• Squid *which began life as a client-side cache
• Apache
• nginx

These are primarily origin servers.

*In computer networking, 'upstream server' is a server that provides a service to another server. An upstream server is a server that is located higher in a hierarchy of servers. The highest server in the hierarchy is sometimes known as the origin-server. There’s a  term known as, downstream server but this term is rarely ever used.

Varnish on Performance

• Varnish performs very well as it is really super fast
• Varnish Cache can speed up information delivery by a factor of several hundred.
• It’s designed to reduce contention between threads to a minimum.

Varnish metrics can be monitored in these areas:

• Client metrics:client connections + requests
• Cache performance:cache hits/evictions
• Thread metrics:thread creation/failures/queues
• Backend metrics:success/failure/health of backend connections

Metric collection:

Varnish Cache ships with monitoring and logging tools are the most used, is the varnish-stat which gives a detailed snapshot of Varnish’s current performance.

It provides access to in-memory statistics such as:

• Cache hits
• Misses
• Resource consumption
• Threads created + more

Varnishstat

Running the Varnishstat from the command line returns a continuously updating list of all available metrics. If the 1st flag is added theVarnishstat will exit after printing the list one time. Varnishstat can be used as a standalone tool to spot-check the health of the cache.

This is done for:

• Graph metrics over time
• Correlate with other statistics across infrastructure
• Set up alerts about any problems that may arise
• Monitoring services that can integrate with Varnish
• Collect Varnishstat metrics

Varnishlog

Is a tool that’s used to debug or tune Varnish configuration because it provides detailed information about individual requests.

Varnish Architecture

Varnish data is stored in virtual memory, the task is to decide what is stored in memory and what is paged out to disk to the operating system. This will help avoid the situation where an operating system starts caching the data while it gets moved to disk by the application.

• Varnish Cache is very heavily threaded, each client connection gets handled by a separate worker thread.
• It is configured to have a limit on the number of active workers on threads that get reached, the incoming connections get placed in an overflow queue and when this queue is reached it gets a configured limit, all the incoming connections will get rejected.

A policy where you can decide on what content you want to serve and from where you want to get the content, and how the request or response should be altered. You can also extend the Varnish Cache with modules ‘VMODs.’

Is Varnish’s Cache flexible?

Varnish Cache is a domain-specific language ‘DSL’ which means it’s also used to write hooks that get called at critical points when it handles each request. Decisions are left to the ‘VCL’ code.

VCL will enable one to write policies on how incoming requests should be handled. Making Varnish configurable and adaptable and more than most other HTTP accelerators.

• The main configuration mechanism for Varnish Cache is the ‘VCL’
• The Varnish Configuration Language sets also have the flexibility of its configuration language.

Varnish Configuration Language (VCL)

Enables a user to write policies on how these incoming requests should or will be handled:

• VCL-  Scripts are loaded
• Then translated to C
• It is then compiled into a ‘shared’object by the system compiler
• It also gets loaded directly into the ‘accelerator’ and can thus be reconfigured without restarting.

vcl_hit subroutine will define how Varnish responds to a request or object that's been cached.

Varnish VMODs - Extensions/Modules

• Varnish Modules also have plugin support, these are known as -  ‘VMODs’.
• It has been written for Varnish Cache.
• Support for ‘Edge Side Includes’, including stitched-together compressed ‘ESI fragments’
• Gzip -  Decompression + Compression
• DNS, Random, Client IP-based Directors & Hashing
• HTTPStreaming - Pass & Fetch
• Persistent Storage support without LRU

cache.org/vmods/howto.html#vmods-re

Load Balancing with Varnish

• Varnish supports load balancing by using both a round-robin and a random director, with a per-backend weighting.
• The health-checking of backends is also available.

Grace & Saint modes:

• Grace mode
  • This will improve the flowing of traffic.
  • Enables Varnish to keep an object in its cache beyond the TTL value.
  • It ignores expiry headers and continues to return cached versions.
  • When a server malfunctions and returns the HTTP status code 500.
  • Varnish will serve the expired and stale content as it fetches a new version of data.

It is used in the following situations:

• The Magento backend is not healthy.
• The Magento backend is not healthy, a request takes longer than usual.
• Saint mode 
  • An example: if a 'backend server' is unhealthy, retries can also be routed to another server.
  • This applies when the Magento backend is healthy.
  • When the load is balancing.
  • Where a failing server is blacklisted for a quarantine period and excluded from the server pool.
  • The Saint mode will blacklist the unhealthy backends, this happens for a configurable amount of time.
  • An unhealthy backend serves traffic when using Varnish for load balancing.
  • It can also be used in conjunction with grace mode to allow for the complex handling of unhealthy backend servers.
  • Saint mode backend hosts and blackout periods are defined in the default.vcl file.

*Saint mode can also be used when a Magento instance is individually taken offline to perform maintenance or upgrade the task/s without affecting the availability of a Magento site.

Saint mode has prerequisites:

• A single machine needs to desinate the primary installation.
• On this machine, you will then install the main instance of:
  • Magento
  • MySQL database
  • Varnish
• The primary machine that has a Magento instance must have access to the MySQL
• The secondary machines must also have access to the files of the Magento
• Static file versioning can also be turned off on all machines.

This data can be accessed from the Admin using:

Stores>Settings>Configuration>Advanced>Developer>Static Files Settings>Sign Static Files, then set value to = ‘No’

All the Magento instances must be using the 'production mode' setting before Varnish will start and to also clear the cache on each instance.

So once again in Admin, you will go:

System>Tools>Cache Management and click Flush Magento Cache. 

One can also run the command to clear cache using the SSH/FTP command:

$ bin/Magento cache:flush

To check feature polls, a Magento server needs to determine if it is responding with good timing. It usually responds to fresh content and it will also be regenerated once the 'Time to Live' (TTL) period expires.

Magento defines the following default health check:

It usually responds to fresh content and it will also be regenerated once the 'Time to Live' (TTL) period expires. Varnish always serves expired content if it's not.

A script must return the response in 2 seconds as the script will determine if any of these resources are down, it will return a 500 HTTP error code. Error code will get received in 6 out of 10 attempts, and the backend will be considered unhealthy.

health_check.php script gets located in Magento’s pub directory. If the Magento root directory is the pub, you need to be sure that you change the path of the URL parameter from:

• /pub/health_check.php 

to

• php.

When Magento’s backend is healthy

• Health checks determine when the Magento backend is healthy.
• A merchant can set the value from Admin just configure Magento to use Varnish.
• Varnish will check whether the time remains in the grace periods.
• If and when the grace period expires, the expired content in the object refreshes synchronously from the Magento server.
• The Varnish Cache will deliver the expired content, and it also asynchronously refreshes from the Magento server.
• Varnish will serve a grace period of an expired object with a maximum amount of only three-hundred seconds by default. For ‘Time To Live’ (TTL) the grace period is 86400 seconds by default.

You can change the default value in default.vcl file, then you can edit the ‘vcl_hit’ subroutine.

if (obj.ttl + 300s > 0s) {

When Magento’s backend is not healthy

• If the Magento backend is not responsive.
• Varnish will serve expired cache for three-days, this gets defined in ‘beserp.grace’
• The TTL period is by default one-day, unless the page is cached the content gets manually purged.

How to generate Varnish configuration?

Magento 2 has a perfect tool to generate a Varnish configuration.

From an in Store>Configuration it could have the following details:

• Access list:local; varnish.local
• Backend host:local

Save the configuration and file varnish. vcl should be generated.

Click one of the export buttons to create a varnish.vcl you can use with Varnish.

If you have Varnish 4. Click Export VCL for Varnish 4.

The figure below shows an example:

Varnish can be tested in various ways

• Magento 2 Varnish test curl
  • Test Varnish using the curl command, you’ll see HTTP headers from the server:

*curl -I *yourdomain.com

• Varnish test in your web browser
  • Open the web browser to type your server URL or address.

*Magento 2 Varnish *test on the frontend

Test Varnish Log SSH/FTP

Varnish provides some commands for managing and viewing logs.

To get Varnish’s access log, we’ll use the command:

$ cd public_html varnishncsa

*Magento 2 Varnish test log

After Varnish has tested the work. You can say its installation and configuration as a reverse proxy for the Nginx web server is completed.

Varnish can also be implemented without having to log Magento ‘Admin’ panel by using a ‘command-line’ Magento Interface tool:

What are the benefits available Varnish Cache?

• Performance + Speed
• Saving Bandwidth
• No more overloads as your site will match any customers’ demand using scalability
• Serving cached content to visitors even if your site is failed, Varnish continues
• So by using VCL you can create:
  • Customized solutions
  • Rules
  • Modules
• By implementing Varnish, you can achieve a better end-user experience.

Varnish Installation 

Once you have recompiled ‘Saint’ mode in general follow these steps:

• Obtain the source code from the Varnish modules.
• You then build the‘source code’ with Autotools.

For more information on Saint Mode please refer to:

Varnish module collection

(*Saint mode doesn’t come as a part of the Varnish package. It is separately versioned in the VMOD that first needs to get downloaded + installed. This as a result needs Varnish to get re-compiled from ‘source mode’.)