Although this process is essential, it’s also intrinsically slower than sending static assets and it uses more server resources. If every part of every page had to be unique, we’d have to live with those downsides, but, in reality, many requests are for pages that are essentially identical. It would be wasteful to generate an identical page every time it was requested by a browser, so we use caching. There are many different types of caching, but let’s focus on Varnish.
Varnish is a caching HTTP reverse proxy, which sounds more complex than it really is. Consider a typical web request to a newly published blog article. A browser sends a request to the web server, which initiates the process we mentioned above. The contents of the article are extracted from a database, combined with a template, processed in various ways, and returned to the web server, which sends the end result back to the browser.
The next time a user requests the same article, exactly the same process occurs. But, if we add the Varnish HTTP Cache in front of the web server, something different happens. This time, the initial request goes to Varnish. If it’s the first time Varnish has seen a request for this article, it just passes it on to the web server as before. But when the web server sends the response back, Varnish will remember it. It stores the page in the server’s memory. Next time a request for that article arrives, Varnish simply sends the copy it already has in memory. The web server, the database, and the code interpreter aren’t involved at all.
Varnish works on a simple principle: it’s a key-value store. It associates a chunk of data with a key, which is used to find that data. In many programming languages this type of key-value data structure is called a dictionary, because just like the familiar word dictionary, a key (the word) is used to look up some data (the definition). In the case of Varnish, the key is a URL, and the data is the web page. If Varnish is given a key that it doesn’t have data for, it just passes the key through to the web server, which generates the pages.
Sending a page from the cache is much faster than generating the page anew: how fast depends on various factors, but it’s not unusual for it to be 1,000-times faster. And because the server has less to work to do, its resources can be used more efficiently.
As you might imagine, I’ve simplified the explanation a bit here – caching, and cache invalidation in particular – is considered one of the hardest problems in computer science, but the basic principles we’ve talked about should help you understand why putting Varnish in front of your Magento store is a great performance optimization and why we developed the Turpentine Magento extension to improve the integration of Varnish with Magento.