StyleFeeder Tech Blog

We recently switched over our static content webserver over to Nginx, easily the most impressive webserver I’ve seen in years. We’re running it on a machine with 8Gb of memory (along with some other stuff), but the nginx process is only using a ridiculously small 1.4Mb. In other words, it barely registers in any measurable way. I’ve seen reports of it handling tens of thousands of concurrent connections on a single box, well beyond where the venerable Apache will scale to.

One unique feature of Nginx is the notion of mirror-on-demand, which I recently explained to a friend as caching but without a removal policy. What we wanted was our static asset server to do was exactly this. We’re using this as a way to get content from our backend app server and then to cache it forever in the filesystem that our nginx servers can read from. It turns out that both Apache and Squid simply cannot do this 100% of the time. Various combinations of Cache-control headers and non-conditional GET requests will cause requests going to the backend, which, in our case, was exactly what we were trying to avoid. Plus, I was also looking for HTTP compression for text/* mime-types. Squid doesn’t do compression, period. It does, however, do de-compression, so you can get gzipped content from a backend server and then serve it up uncompressed, which may be useful in some arcane cases.

I should mention here that our first choice was actually to use Lighttpd with mod_cache, which is capable of doing this kind of “only retrieve this content from the backend exactly once” caching. However, within literally minutes of deploying, we ran into corruption issues with some Javascript and CSS content that we didn’t detect during our testing. I saw many instances of corrupted cache content during the time that we used Lighttpd and mod_cache and quickly decided that I needed to explore other options.

Our experience with nginx was great from the start. Most of the docs are in Russian, but the English docs are very well done and quite adequate all around. Configuration is a cinch and deployment was easy as pie. The only hiccup was that I noticed that nginx does not set a Content-length header on content that has undergone HTTP compression (gzip). This is minor for our purposes.

In short, nginx rocks hard.