High perfomance TYPO3 with varnish proxy

Af: Jan-Erik Revsbech

Take a look at how we managed to increase maximum peak performance at least 7 times using a reverse proxy on a TYPO3 site.

The graphs are showing the number of incominc connections on the proxy.

For the last year or so, we have had the privilege of hosting a subsite of the danish newspaper bt.dk. The site is targeted towards women, and is very heavy on graphics, most of it dynamically generated PNG's made with TYPO3s GIFBUILDER. 

The site is fairly visited during normal hours, but we are experiencing a very large increase in traffic, when a link to the site is put on the frontpage of bt.dk. Usually we experience a few hundred connections during such peak-hours.

The site is not specifically built for this kind of load, and we had problems with very long response times. We actually had to limit Apache to a maximum of 125 simultaneous connections, in order to keep the server from spiralling into unresponsiveness.

Together with the agency that made the site, we decided to put a reverse proxy in front of the site to cache a lot of the requests. The site has no login features.

After investigating the market, we decided to go with Varnish, primarily because it is built for exactly this, and also because it had a straight forward configuration language.

The configuration

We decided to go with a simple setup. We disrespect TYPO3's no-cache headers (sorry), and cache all HTML for 60 seconds even though the headers have a no-cache pragma. We decided that all image-material could have a longer lifetime, and thus cache it longer (about an hour).

Only GET-requests are cached, since we assume that a POST is probably the result of submitting a form, and we do not wish to cache this. Similarly we check if a typo3 backend cookie is present, and that will disable cache (except for images).

This setup, although simple, turns out to work very well for sites with no front-end login.

One last thing, we have a rule that checks for force-reload, not only will a force-reload disable cache for that request, but will also purge the cache, thus rebuilding it again. This way a TYPO3 editor can force re-caching of a certain page. 

Of course the right solution is to make a small TYPO3 module that clears the varnish cache after a page is saved (or any other action  that triggers clearing of TYPO3's internal cache). But for the sake of simplicity this is omitted here.

A slightly modified version of our basic configuration file is attached to this blog post.

Results

We have been fairly surprised with the result. We have seen a very large increase in perfomance, both under high load, but also for single page-impressions. Since the images are cached (and correct Expires-headers are set) the page loads very quickly compared to before the cache setup.

Today the setup was tested even further. An article was put on the very top of bt.dk, and apparently is was very popular. We were alerted that the number of incoming connections on the proxy were a constant 700 and increasing. Looking at the graphs, we could see that neither the proxy nor the actual TYPO3 sever was under any load. Both had a load below 0.5, and a quick investigation showed that the site performed well within the limits of responsiveness.

We can conclude that the setup is really working, and that we would probably be capable of handling a much higher load than the one we experienced.