Q. Why is Varnish recommended so often for Drupal websites?
In a word – scalability. For each end user accessing the backend of your Drupal site, queries are made between the site and the site’s 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, delivering the content your users want to see at a rate that won’t lose their interest.
Q. How does Varnish work to protect my site from heavy traffic?
Varnish acts as a shield between the user and the backend of your site. When a user requests a web page from your server, Varnish will, when possible, store the requested content in its memory cache. When future requests are made, Varnish will check its internal cache before the request hits your server. If it finds the requested page, it will serve it to the user as a static HTML page, saving the backend of your site the work it would’ve taken to generate that same page dynamically. Visitors to your site see the same content at a drastically reduced response time. In the words of Acquia’s cloud engineering manager Erik Webb, “caching is the single best way to improve Drupal performance without having to fiddle with code.” It’s worth noting: as an external cache service, Varnish can only handle anonymous user requests. If a registered user is logged into your site, pages they request will include dynamic, personalized content that must be constructed by your server, or stored in an active, internal cache. However, as the bulk of a site’s traffic comes from anonymous visitors, Varnish will more than pull its weight.
Q. I already have a caching service. Do I still need Varnish?
In his post Explaining Varnish for Beginners, Adam Malone provides a comparison list of alternative caching options, and in each case assesses the strength of Varnish when used instead of – or alongside of – other software. Varnish comes out ahead of Boost and Drupal’s built-in database cache system, but really shines when used in tandem with Memcache, Redis, or MongoDB. This is because software like Memcache works as an active cache that Drupal can interact with to retrieve and deliver cached pages requested by logged in users, whereas Varnish exclusively serves content to anonymous users. Implementing both caching strategies simultaneously will minimize resources used by your site’s backend, and maximize delivery speed to your visitors.
Q. What happens when I update my site’s content?
Varnish will only hold cached pages in its memory for a default time of 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 need be, 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. If you want to purge content specifically within the Acquia cloud environment, you’ll be happy to learn that the process is incredibly simple. The Drush command to purge a domain from Varnish cache is: ac-domain-purge The command to purge a domain from the cache without Drush, using the Acquia cloud API, is: DELETE /sites/:site/envs/:env/domains/:domain/cache You can even automate the process. The Acquia Purge module allows Drupal sites to proactively purge pages from the cache when their content has been updated.
Q. What do I need to know to implement Varnish?
Take a look at the Drupal community documentation, as well as this tutorial on how to get Varnish up and running for a Drupal site. Once you’ve got Varnish working for you, the vcl documentation will help you configure your setup to create the best fit for your site.
