In our first Chalk Talk video, we said that Varnish could speed up your website quite a bit. But Varnish is a complex tool. That is why we go into further detail about how Varnish works, in our second Chalk Talk video.

The written text of this Chalk Talk, “How does Varnish work?”

Welcome to Chalk Talk, a series of video’s where we explain complex technologies using a single chalk board. In this video we talk about Varnish and how that fits into your infrastructure. So we will be looking at Varnish in detail. How it works and how it unifies client- and server requests.

How does Varnish work?

Varnish is a piece of technology that sits between your customer and your server, in order to speed things up. This is what it looks like …

Your customer, sitting happily behind his laptop, is going to make a connection to your server and wants access to your website. He will connect to Varnish, this entire box, and Varnish will look in its cache to see whether there’s already an answer for that specific page.

If it’s not the case, Varnish will send a request to the webserver. This is where your PHP connects to your database, your Redis, your API calls … This is why it takes some time to display a page. As soon as that job is done, the webserver will send it over to Varnish. Varnish then stores it in its cache and delivers it to the end-user.

The next time someone visits that page, or the same users returns, Varnish will look in its cache again, but this time it will find that exact HTML page. Varnish then shows it to your customer, only this time in milliseconds instead of seconds.

The different components of Varnish

Each of these blocks can be fine-tuned by you or us: the part where the user connects to Varnish and the part where Varnish connects to your webserver. You can add logic to remove cookies or URL parameters, or normalize the host-header. It’s all possible in this block.

When you send a request to connect to the ‘slow’ webserver, you can add debug-headers, add extra information to give you an idea, server-side, of what your customer has asked. Extra headers, manipulating cookies, etc.

As soon as the server is done with all these things, you arrive at another block you can also fine-tune. Adding or removing headers … whatever you want.

Next you are going to caching, the heart and soul of Varnish itself, where you can fine-tune what is defined by a certain URL.

When I visit your site or my colleague does, and you have for example a shopping cart, the result will be different. Cache is where you determine what parameters are used to recognize my request versus that of my colleague.

The VCL_deliver part is the last part before your data is sent to a customer. And also the last part where you can clean up. Suppose you had debug headers, this is where you can remove them before they arrive at your customer.

Varnish Configuration Language (VCL)

The final result is a fast experience for your visitor. You achieve that by setting up Varnish with C-type configuration syntaxes. It’s a VCL file, the Varnish configuration language. You can program Varnish to do anything you want it to. You can remove headers, you can add headers, and you can rewrite certain URL’s to other URL’s. It’s a very complex and very extensive configuration file to do things in.

The tricky part is where to draw the line between what is done by your webserver versus what is done by Varnish. It’s a very thin line. Ideally you keep Varnish as simple as possible and you do everything in your PHP, your Perl– or your Ruby-application. Varnish gives you the ability to fine-tune every aspect of it.

The difference is that your site can go offline because of 10 users or survive with 10.000 users, simply by adding Varnish.

Key takeaways

Remember: Varnish is a complex piece of technology that we can help you configure. Ideally you keep it as simply as possible and all your application logic is found in your actual application.

Next time in Chalk Talk?

In the following video’s we look at content strategies for your website, how you can debug Varnish and how you start using it. See you soon for a new episode of Chalk Talk!

Related posts
PHP Benelux 2018

PHP Benelux 2019: 7 things that we will remember

For two days PHP Benelux 2019 was the place to be for anyone who works with PHP. A quick overview of the most important takeaways.

Read more

visies meet the hackers

Meet the hackers: three perspectives on security

Better safe than sorry was the message behind ‘Meet the hackers’, our workshop on ethical hacking. In the cosy setting of the Mariaburg barn, […]

Read more

gdpr voor developers

GDPR: practical tips for developers

There’s already a massive amount of information around concerning the GDPR, especially for CEOs, CIOs, and marketing managers, but what about GDPR for developers? […]

Read more