If you know that you'll have a large group of website visitors that periodically (and simultaneously) visit your website for the same content, it doesn't make sense to size your server large enough to handle even the largest possible group of website visitors. Instead, you would make your site's content available to an application that can serve copies of content instead of having to re-create each content page dynamically for each website visitor. One application used for this purpose is Varnish.
Varnish is a reverse proxy HTTP accelerator that is often placed in front of Drupal websites to cache content, usually for anonymous website visitors. Varnish is used to serve content from your webserver without actually overburdening your Drupal web-server. Drupal's caching system stores cached content in its database, while Varnish's cache stores the cached content in memory on the webserver. Additionally, it is server platform agnostic. It can work on web servers running Apache, Nginx, Comanche, or Internet Information Services (IIS).
The following information about how Varnish works is provided by Acquia's Knowledge Center:
Why is Varnish recommended so often for Drupal websites?
In a word – scalability. For each end user accessing the back end of your Drupal site, queries are made between the website and the database, active cache, spam filter, and update service. A web page is then built dynamically and delivered to the user. This system works fine for low-traffic sites, but if you’re looking to support the heavy traffic a large audience brings, your server alone will struggle under the weight. Varnish works to take the load off of your server.
Varnish is transparent to website visitors, handling content requests between website visitors and the web server backend. Any content presented for display by the server (surfaced) also includes the correct cache headers and is stored for a limited time. The are many advantages to using Varnish, including the following:
- Serving content from an in-memory cache means no slow PHP execution and no slow MySQL queries.
- Varnish delivers content at a much higher rate than stock Drupal can.
- The headers are respected entirely from Drupal, so unless something is specifically overridden in the Varnish configuration, Varnish will cache whatever content Drupal directs it to cache.
All of these together make websites behind Varnish fast! Even though the effects are felt only by anonymous users, the majority of traffic for most websites is likely anonymous so the benefit would be great.
Verifying that Varnish is working/applies to your Site
One of the easiest ways to ensure that Varnish is working as expected is to visit the Is Varnish Working website and enter your website's URL. If Varnish is working for your site, it displays Yes! along with your site's headers.
What happens when I update my site’s content?
Varnish will, by default, hold cached pages in its memory for two minutes. After this period, the page will be discarded from the cache. The next time this content is requested, it will be created and delivered by the backend, and a new static copy will be stored in the Varnish cache. If necessary, you can manually invalidate cached objects by either purging them from the cache or banning them from being served from the cache. Varnish Software provides training material for these cache invalidation strategies, and you can find resources in pages linked to this one.
Bypassing the Varnish cache
While it's very important for your site to use a Varnish cache to perform and scale well, when you have a few pages with random or dynamic content it can be a valid business requirement to selectively exclude certain paths from being cached so that dynamic content is actually dynamic. The most obvious way to achieve this would be to alter the Varnish Configuration Language (VCL) file. However, this may seem excessive. Not only does it require dedicated load balancers on Acquia Cloud [or your hosting provider], but this is something Drupal can handle very well at the application layer.
Types of content that you could set to bypass Varnish caching include:
- Individual Detail Pages for various content types
- Landing pages representing a subsection of your website
- Listing pages for content types
Should you need to bypass Varnish caching for a section of your site, type of content, or block on your site- please consult your developer/site administrator for setting up the caching bypass rules.
Blocks
Blocks may not always clear from the cache, even if you have forced a cache clear of a page the block appears on. The nature of blocks allows them to appear on multiple pages; if you only clear one page that the cached block appears on, the cached version may remain for other pages.
There are ways to force Drupal to bootstrap and clear the block cache for a particular block, but it can severely degrade your website performance. In many cases, it's safer to occasionally clear the cache for all blocks, rather than to try to force a few specific ones. [This feature may be limited to site administrators and developers only.]
Purging Varnish Cache
There are major advantages to having long cache lifetimes and expires, which means that it's important to use Varnish with Drupal for performance improvements. However, when changes are made or new content is published, you don't want to wait a long time for visitors (including non-authenticated users) to see the changes. In these cases, you should periodically purge your Varnish cache.
Varnish excels at storing pages, CSS, and JavaScript files, as well as multimedia files, for as long as possible, so that visitor requests don't hit the back-end (in most scenarios, this will be Apache). This greatly helps with performance and allows a website to scale much better than it would if only Apache was serving pages. When your organization decides to implement a caching strategy, you will need to explore all available options and decide what's best for your situation.