If you have huge amount of money, you can just keep throwing hardware at scaling problems. For the rest of us, though, performance tuning is a must.<\/p>\n
Note<\/strong> – Incidentally, if anyone with monstrous gobs of cash is actually reading this book, please<\/p>\n consider a substantial donation to the Django project. We accept uncut diamonds and gold ingots, too.<\/p>\n Unfortunately, performance tuning is much more of an art than a science, and it is even more difficult to write about than scaling. If you\u2019re serious about deploying a large-scale Django application, you should spend a great deal of time learning how to tune each piece of your stack.<\/p>\n The following sections, though, present a few Django-specific tuning tips we\u2019ve discovered over the years.<\/p>\n There\u2019s No Such Thing As Too Much RAM<\/strong> – As of this writing, the really expensive RAM costs only about $200 per gigabyte \u2014 pennies compared to the time spent tuning elsewhere. Buy as much RAM as you can possibly afford, and then buy a little bit more.<\/p>\n Faster processors won\u2019t improve performance all that much; most Web servers spend up to 90% of their time waiting on disk I\/O. As soon as you start swapping, performance will just die. Faster disks might help slightly, but they\u2019re much more expensive than RAM, such that it doesn\u2019t really matter.<\/p>\n If you have multiple servers, the first place to put your RAM is in the database server. If you can afford it, get enough RAM to get fit your entire database into memory. This shouldn\u2019t be too hard. LJWorld.com\u2019s database \u2014 including over half a million newspaper articles dating back to 1989 \u2014 is under 2GB. Next, max out the RAM on your Web server. The ideal situation is one where neither server swaps \u2014 ever. If you get to that point, you should be able to withstand most normal traffic.<\/p>\n Turn Off Keep-Alive<\/strong><\/p>\n Keep-Alive is a feature of HTTP that allows multiple HTTP requests to be served over a single TCP connection, avoiding the TCP setup\/teardown overhead. This looks good at first glance, but it can kill the performance of a Django site. If you\u2019re properly serving media from a separate server, each user browsing your site will only request a page from your Django server every ten seconds or so. This leaves HTTP servers waiting around for the next keep-alive request, and an idle HTTP server just consumes RAM that an active one should be using.<\/p>\n