by Alex Holt | Dec 11, 2011 | Dev, Server |
My sites are hosted on a VPS (with very sparse memory allocation), so i’m looking to minimise memory usage wherever possible. I also had the joy of watching my Django FCGIs for http://the-hive-mind.com get completely annihilated by metafilter.org a few weeks ago – i think it stood up to the first 200-300 requests.. then completely died. Anyway, I have just launched a website for a friend in Nepal, who runs a trekking business (he comes highly recommended if you ever want to go hiking in that region). Basically, I decided to try and load test the Django instances on the site, to see how much traffic it could handle… i downloaded and installed siege.. which (as the name suggests) lays siege to your web server. My out of the box Django FCGI being called by a Nginx instance was only capable of reliably handling up to about 10 concurrent connections before it started dropping requests.. not really acceptable (caching, at this point.. was completely turned off). So I set about sorting out caching. I read the Django documentation.. and quickly decided that the built in caching wasn’t quite to my liking. I already knew a little about memcached, and wanted to use it to cache my generated responses, so the fact that Django supported it was nice. However the idea of using a the Django cache middleware doesn’t really cut it. Nginx supports memcached.. so why would i want to fire the request off to my (inherently bulky and inneficient) python FCGI instance? just to use python’s undoubtedly slower memcached library to return the cached content? I wouldn’t. The solution I’ve come up with is somewhat simplistic, however it DOES...
