skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters

Serving Up TAMUtimes

September 16th, 2011 by tamuwebmaster

In a blog post two weeks ago, Erick introduced our latest website, TAMUtimes. While that post is a great introduction to the idea of TAMUtimes it doesn’t shed much light on the technical hurdles of serving the site and emails to the audience. In this post, I’ll discuss the technologies that allow us to handle the traffic generated from bulk emails and subsequent page views.

The TAMUtimes application server

As he mentioned the application is running on WordPress. What he didn’t mention is it is running as part of a WordPress 3.0 multisite installation along with two other blogs we maintain. The application itself is served by Apache and has a MySQL service running behind it. As you can probably imagine, this is an incredibly slow configuration.

Under normal operations, with the help of a simple caching plugin, this configuration would limp by and we’d be able to expand it if demand for any of the sites increased. But we didn’t have such a luxury on a site whose main traffic would be generated by a bulk email that would eventually be sent to over 300,000 individuals relatively simultaneously. We needed something to handle the load.

Enter a reverse-proxy cache

You might have already guessed, but this site is a perfect candidate for a reverse proxy. After some discussion, we chose to give Varnish a try. I experimented with Varnish on some personal projects, so I already had an idea of the impact it could have sitting in front of Apache serving up WordPress projects, so it wasn’t a difficult decision.

I ran some benchmarks using the Apache Bench tool (ab2) and found the Varnish server increased the mean number of requests per second we could handle by roughly 6,500%. In the benchmarks, the server was able to complete 959 requests in 200 seconds without Varnish, whereas it completed 50,000 requests in 158.8 seconds with the proxy cache in place.

One step further

At the same time, we noticed that other emails being sent to large distribution lists also caused some lag on some of our servers (because of the images included in the email.) Modern practices dictate that we should move our images to a separate domain name (or subdomain in our case) so that’s what we did. We stood up a server running Nginx to handle static assets such as image, stylesheets, JavaScript source, etc. with far-future expiration dates and a few other tweaks. We moved the TAMUtimes images (as well as many other images) to the static assets server, and haven’t looked back.

The final result

As a result, when the email goes out for TAMUtimes, we don’t see a spike on the Apache server—whereas in my benchmarks it was customary to approach the “time to swap” line if not to cross it and not look back. We haven’t yet seen a spike in usage on the assets server, and I don’t foresee one anytime soon.

The moral of the story is to always benchmark your applications and your systems serving them up well in advance of deployment. If we hadn’t, several of our systems would have fallen flat on their proverbial faces.


Friday, September 16th, 2011 Miscellaneous, Systems
Share this article

No comments yet.

Leave a comment