One thing that always bothered me with staticgenerator is that nginx had to gzip the same html over and over again on requests with the Accept-Encoding: gzip header. Now that I found love with gzip_static it’s super easy to serve precompressed .gz files with nginx. The feature it self has been around in nginx for a while but it wasn’t untill recently it got to my attention.

Since I already have one fork of staticgenerator at github I choosed to fork from Erik Karulf instead. I wanted his excellent changes which enables atomic file generation anyway.

So straight from the oven, staticgenerator with atomic file generation and atomic gzip support. I’ll ping Jared Kuolt on github and hopefully he will merge mine and Erik’s changes into the main repository and makes a new release.

Feel free to post feedback of any kind in the comments.

gzip_static enables nginx to check for pre gzip’d files so it doesn’t have to gzip the same content over and over again, which saves you a lot of cpu on high traffic sites. Say you request /foo/index.html with Accept-Encoding: gzip and there is a file in your doc root foo/index.html.gz, nginx will then take that index.html.gz and serve it instead of gziping foo/index.html on the fly.

Upgrading and compiling deb packages seems to be easier than ever, I found a tutorial on the ubuntu forum which explains in just a few steps on how to always have the latest nginx available in a ubuntu fashion (conf in /etc/nginx, startup script in /etc/init.d and so on). I guess the tutorial works for 0.6.x versions aswell as 0.7.x. I only tried 0.7, not that I need any specific 0.7 features but I like to have the latest and greatest :)

Anyway if you still don’t want to compile it, you can download nginx_0.7.54-0ubuntu1_i386.deb from my public files section.

$ wget http://god.morgon.nu/public/nginx-jaunty/nginx_0.7.54-0ubuntu1_i386.deb
$ sudo dpkg -i nginx_0.7.54-0ubuntu1_i386.deb

I don’t have any energy to put up an apt repository but chances are I will keep publishing new nginx packages on there. Keep in mind I only have 10 mbit up, feel free to mirror it and include a link back to this post or post a mirror link in the comments. Also feel free to post comments if you like this or if you have any feedback.

The bad parts of making the switch was that I needed to bloat my precious server with mysql and php ;)  I might move to Zine when it gets a little more mature but for now I really don’t care. Anyway. Basicly it’s the wp-super-cache plugin that makes the most from a performence perspective. It’s pretty much staticgenerator for wordpress, it generates static html files from the blog. But instead of letting the proxypassed apache serve those html files, I of course serve them with nginx. Not only is it faster, it let’s me fine tune the config in ways apache doesn’t, beacuse of it’s support for if statements. That makes it easy to serve the cached created files with expire headers.

if (-f $document_root/$supercache_file) {
  rewrite ^(.*)$ $supercache_file;
  expires 1h;
  break;
}

Obvious overkill you might think. But fact is I don’t post new posts very often, so why should one need to download the same html twice? wp-super-cache also generates gzip’d files, so you don’t need to waste cpu on gziping the same html over and over again. With gzip_static in nginx this is possible. If you request /foo/index.html with Accept-Encoding: gzip and have gzip_static on, nginx automaticly checks if there is a file /foo/index.html.gz and serves it.

Does all this makes this site diggproof? I don’t know for sure. I guess it all depends on my bandwidth (10 mbit up should be enough) and also if many people makes comments on the same time. Chances are pretty low I will get that much traffic anyway. But a fast site makes visitors happy anyway.

It’s pretty much a drop-in replacement for StaticGenerator except that you need to edit your settings.py to use memcached as cache backend.

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'

And of course you need to update your nginx config. It could look like something like this:

# This example configuration only shows relevant parts
# It assumes your django app is served via http on localhost:9004
location / {
    #pass POST requests to django
    if ($request_method = POST) {
            proxy_pass http://localhost:9004;
            break;
    }
    default_type  "text/html; charset=utf-8";
    set $memcached_key "$host$uri";
    memcached_pass localhost:11211;
    error_page 404 502 = /django;
}

location = /django  {
    proxy_pass http://localhost:9004;
    break;
}

I tried to cover everything in the README.

Bonus feature!

I included one bonus feature not exisiting in StaticGenerator. You can add the following line to your settings.py which will make StaticGeneratorMem not to put responses in memcached if there is any user logged in.

STATIC_GENERATOR_ANON_ONLY = True

You can the modify your nginx config to something like this. Note that you need to edit the domain field for your settings id in your database to reflect the server_name which is used in the memcache key. You can also set it as SERVER_NAME in settings.py if you are not using contrib.sites.

# This example configuration only shows relevant parts
# It assumes your django app is served via http on localhost:9004
location / {
    #pass POST requests to django
    if ($request_method = POST) {
            proxy_pass http://localhost:9004;
            break;
    }
    #pass logged in users to django
    if ($http_cookie ~* "sessionid=.{32}") {
        proxy_pass http://localhost:9004;
        break;
    }
    default_type  "text/html; charset=utf-8";
    set $memcached_key "$host$uri";
    memcached_pass localhost:11211;
    error_page 404 502 = /django;
}

location = /django  {
    proxy_pass http://localhost:9004;
    break;
}

And logged in users will hit the django app with a dynamic request instead of the cached content in memcached. If you changed the cookie name of your session id to something else than sessionid you need to take that into consideration aswell. From my experience this doesn't work 100%, if a user logs out the cookie usally remain with an invalid session id which will cause logged-in-and-then-logged-out users to hit the django app directly and not cached content. On a blog or content heavy site which is StaticGeneratorMems primary usage this would only be you and any other authors so it's probably not a big deal, just something good to know.

Should I use this or StaticGenerator?

This is totaly up to you. Both will give you excellent perforemence boosts though StaticGenerator will give you the best performence. If you prefer puting cached things in memcached, using StaticGeneratorMem is a neat way of doing it. With StaticGeneratorMem a restart of memcached and the cache is gone. More on this in my previous post about this.

That's all for know. Remember to tail your apache (or whatever httpd you are using) access log side by side with your nginx acceess log to make sure that only the first request hits both servers and the second only nginx. I'd be glad for any feedback on this.

Benchmarks

Some people chooses strategy after benchmarks numbers without any other considerations so I’ll start by just stating that nginx serves static content ~270% faster than memcached content and Im sure some people stops reading here and goes with staticgenerator.

I didn’t just make that number up, I used the excellent httperf with the following settings:

$ httperf --client=0/1 --server=foo.bar --port=80 --uri=/test/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1 --num-calls=10000

With a static html file on /test/ i got this result:

Request rate: 6243.8 req/s (0.2 ms/req)

And with the exact same html in memcached i got this:

Request rate: 2285.5 req/s (0.4 ms/req)

These benchmarks were made with “warm cache”, the html file was pregenerated aswell as put into the memcache before the tests were made. So does this mean nginx is actually 270% faster on serving the same html from static files than from memcached? No. I don’t have any proper benchmark environment. This numbers just gave me hints about nginx being faster on static content than serving from memcached with its memcached module and most important, the test numbers made me thinking about what was going on behind the curtains.

Interpreting the benchs

I think one of the reasons the memcached solution does’nt perform as well as static files is that on every single request the nginx needs to open up a new tcp socket, handshake with the memcached etc. Hold it right there, this is starting to sound like a dialog from 24 with Chloe O’Brian. Im not familiar with the core stuff of the tcp protocol but what I mean is that on every single nginx request, nginx has to connect to the memcached, there is no keepalive or persistent connection between nginx and memcached. Running both memcached and nginx on localhost may not add any significant delay, but the fact that it’s a completly another program with its own processes that nginx needs to “connect to”, and wait for an answer is pretty clear to me that it adds some delay on vs just serving the file from local disk within the same process.

But doesn’t serving static files means that nginx hits the disk on every request? Yes and no. All *bsd and linux systems (I can’t speak for windows) has excellent fs usage. Frequently requested files are cached automaticly by the os,  though the files are stated on every request to see if they have been changed for example. The above benchsmarks was done on two laptops (with 5400 rpm drives), one with nginx and memcache and one running httperf. With 5400 rpm drives.

Conclusion

Either you choose to use staticgenerator or one of the memcached ways you will speed up your site significantly. If you want the fastest available option use a staticgenerator with a ramdisk (mount some of your ram as a dir). Generally I think it’s a cleaner concept to put generated content in mem instead of disk. A restart of memcache and the cache is gone. Also, your memcache doesn’t need to be running on the same machine as the nginx or the webapp. It makes it easier for flexible setups and scale, pushing around static files over network with scp/rsync/nfs/<your preferred tool for moving data over network here> is messier but fact remains static files are served faster.

Consider adding expires headers on like 1 hour and clients browsing around the site will not even have to download the same html over and over again aswell. But then clients won’t necessary always see the latest content you say? They may not, you could adjust the expire header depending on how often you post to your blog or how often you update your content.

I use these strategies even on sites without any load. Why? When that somebody actually visits the site I wan’t it to be served as fast as possible. Performence and usabillity goes hand in hand, a fast experience is a good experience.