Yale Daily News Online

By: Robert Baskin (Online Director)

So finally we come to the Server header, which I have alluded to previously. When you make a request to our server, we send back many “Headers” for each request before we send back the actual content you requested. They include things like Size and Expires headers. The best way to see all of the headers, and much more information about how your browser loads our page, is with the Firebug extension for Firefox. The Net tab will show you each request as it’s made to our server - how long it took, the headers it returned and the content we sent back. Examples of requests are for the main HTML page, each CSS and JS file, images and Flash objects.

Anyway, if you take a quick look, you’ll notice that our Server header is “nginx/0.5.26″. (Note: Don’t look on this blog; it’s not hosted on our production server. Look on YaleDailyNews.com.) Anyway, you might notice that’s not one of the two servers that run the vast majority of Web sites out there on the Internet - Apache and Internet Information Services (IIS). We used to send back Apache headers, but what is nginx?

To quote the English version of its documentation (it’s a Russian product), “Nginx (pronounced ‘engine x’) is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.” Essentially, nginx is a FAST Web server. It’s great at handling requests for static files - CSS, JS, images, etc. Its downside is that it’s not very good at serving requests for dynamic pages: anything that involves parsing server-side code, which is PHP in our case.

So we decided to use nginx in what’s called a reverse-proxy. When you make a request to our Web server, nginx handles that request. It checks to see if the request is for a static file. If it is, it serves the file. That’s much faster than Apache! Under the old system, Apache was serving both dynamic requests, which it’s good at, and static requests, which in a LAMP configuration it is not very good at. In order to serve simple CSS files, it had to use its heavy PHP-interpreter-laden process to serve that request, which is quite memory-intensive and relatively slow. Nginx is much faster.

But what about dynamic requests? After checking to see if the request is static and serving it if so, nginx passes on all other requests to Apache, which is better at handling PHP requests. Apache is running on our server on another port, so nginx passes the request to localhost on that port. Apache sees that request, generates the page using PHP and passes the content back to nginx, which sends it back to you.

I wish we had better numbers, but we didn’t really do as much benchmarking as we should have. One of our main bottlenecks is memory (especially now that we’re doing view caching, which will be the subject of my next post), and nginx uses much less memory than Apache, so we’re able to serve more requests without overloading our server. I’d estimate a 20 percent increase in requests per second.

The other alternative we considered was moving our static assets to Amazon S3. However, in order to do so, we would have to do some reworking in our code to point to the right images location, we’d have to develop a deployment process to synchronize to S3 and we’d have to pay for Amazon’s bandwidth costs. We may revisit the idea in the future though, as well as considering moving to Amazon EC2 for hosting as well. However, for the time being, nginx was an easy and helpful solution.

Sorry about the delay. Posts should come more regularly now. I’m aiming for one every week, but don’t hold me to it!