= Load Balancing and Django = == NOTE: THIS DOCUMENT IS INCOMPLETE. It is currently undergoing heavy editing, and I make no account for its accuracy as of this moment. -James Crasta == It all started with this IRC conversation on 2006-06-30: {{{ 13:55 < mattmcc> There isn't really much about load balancing that's Django-specific. 13:55 < brantley> Mike: I don't think so. 13:55 < Crast> mikearagua: no, but that's not really a django-specific topic anyway, it's more a webserver-config and DNS 13:56 < brantley> Personally, if I were to do that, I'd setup a specific box as the database-box, everything else would pretty much fall into place. 13:56 < mikearagua> yeah, i know, i just assume there would be particularities when doing it with a django app 13:56 < mattmcc> Not really. 13:56 < Crast> I have loadbalanced django using fastcgi and a single lighttpd in front, no proxying, and it worked... but I had no reason for it except for as proof-of-concept 13:57 < Crast> lighttpd does a decent job of load-balancing fcgi 13:57 < brantley> Crast, was that on multiple machines? 13:57 < Crast> brantley: yessuh, though admittedley one of them was the lighttpd machine itself 13:58 < Crast> I took that one out of the loop and substituted a laptop just to see how things would change 13:58 < brantley> Hrm, I don't understand, exactly... Lighttpd sent the requests to fastcgi's on different servers? 13:58 < Crast> and the database server just ran on the lighttpd machine 13:59 < Crast> brantley: yep. you can specify multiple fastCGI servers to a single path using lighttpd 13:59 < brantley> Damn, I didn't know that. 13:59 < brantley> That's pretty sweet. 13:59 < brantley> Yeah, Mike. Do that. 13:59 < benbangert> Crast: lighty has some issues dealing with dead FastCGI processes 13:59 < Crast> therefore you don't get all the ugliness of HTTP proxying 13:59 < aurynn> yay 13:59 < Crast> benbangert: I don't use lighty to spawn the processes though, since they're not even running on the same machine 13:59 < mikearagua> i was mostly thinking about issues with session state 14:00 < benbangert> ie, when a Fast CGI process stops responding, it takes awhile before lightty will shut it down and restart it 14:00 < aurynn> automatic cpu underclocking, as well as load-based rampup fills me with complete joy. 14:00 < Crast> benbangert: however, you are correct 14:00 < benbangert> Crast: yea, but it doesn't seem to do a very good job noticing when a FCGI connection has stopped answering requests 14:00 < brantley> Err, I think the sessions are handled in the database with cookies, it should be fine. 14:00 < benbangert> I heard pound is really slick 14:00 < benbangert> http://www.apsis.ch/pound/ 14:01 < Crast> benbangert: that's due to the natural timeout of the protocol though, it doesn't "not notice" it just allows sufficient time to complete the request 14:01 < mikearagua> brantley: that's exactly what i wanted to know 14:01 < mikearagua> thanks. 14:01 < brantley> I can't give you an exact affirmative, you should probably ask on django-users. 14:01 < brantley> But I'm pretty sure that's how it works. 14:01 < Crast> yeah, sessions are stored in the DB 14:02 < Crast> serialized python dicts more or less 14:02 < brantley> And hooked up through cookies. 14:02 < brantley> And as long as the browser thinks it's the same server, it'll work fine. 14:02 < Crast> yep 14:02 < mikearagua> it seemed that way to me but i could have been missing something 14:02 < brantley> Also: I would create a specific server that is dedicated to serving media. 14:03 < mikearagua> maybe i should start messing with lighttpd. i use apache mostly 14:03 < brantley> With big fast hard-drives. 14:03 < Crast> well you do have a possible concurrency issue if two processes are using a session at the same time, whicever one writes second writes the finished session, however that'll happen even without load balancing, and it's really a non-issue 14:03 < brantley> That's really the database that needs to care about that, it seems to me. 14:03 < brantley> The first "load-balancing" should be separating the application server from the media serving. 14:04 < brantley> Then you go from there. 14:04 < Crast> I don't mind writing up a doc of my experimental results 14:04 < mikearagua> that would be cool 14:04 < brantley> That would be very progressive for enterprise Django. 14:04 < mikearagua> i could add to the doc as i go. i would like to do some testing with load balancing before i deploy my app 14:05 < Crast> so I'll put the doc on the wiki then 14:05 < mattmcc> Serving the static media on a separate box is definitely the first step. Optimizations for that server will be quite different from the ones serving up python. 14:05 < mikearagua> yeah, that's fairly easy though 14:06 < mikearagua> there are lots of docs describing how to serve static files fast 14:07 < mikearagua> especially with apache. there are some issues with having dojo on a separate domain name though that i've run into so for the time being i'm running both off the same machine 14:07 < Crast> benbangert: there's a "disable-time" option to fastcgi servers, perhaps that needs to be tweaked for loadbalancing to be effective 14:07 < Crast> (on lighttpd, that is) }}} There are a few approaches to load balancing, and in many cases, they can be combined (some large websites use more than one of these strategies) 1. '''Round Robin DNS''': Involves setting up multiple DNS records for the same hosting domain. * ''Advantages'': Very simple to set up, mostly does not require any special server setup at all. Machines serving the site can be as geographically dispersed as you wish. You can also round-robin more than just web requests, so even things like FTP, IRC, and many other services can be load-balanced this way. * ''Disadvantages'': The round-robin DNS is picked by your local DNS server serving you recursion results (usually your ISP for most end-users). There's no nice way to "switch" users down to another server if one server is overloaded or down, and making changes to the DNS can take days to propagate across DNS caches. It's very difficult to track if users are unable to access your site, since they may be sending requests nowhere. 2. '''Reverse Proxying''' Using a front-end server or dedicated hardware device in front of multiple web serving. * ''Advantages'': This allows a web site to be served by multiple independent web servers. Most load balancer solutions include tools for monitoring server load and appropriately sending requests to the least-busy servers, and performing proper failover. With appropriate hardware this can scale to very large proportions, and achieve very good uptime / consistent performance. * ''Disadvantages'': Set-up is tricky, and load-balancer hardware is often expensive. In most set-ups, the static files have to be mirrored to all the web-servers, and every machine has to be running a full webserver stack. Some issues pop up with things like some HTTP meta-information being lost due to the proxying. 3. '''distributing dynamic content-generating processes''' * ''Advantages'': * ''Disadvantages'': == Example "traditional" Load-balanced network layout == Obligatory ascii art diagram follows: {{{ ---------- ((( INTERNET ))) ----+----- | | | +-----------+ | Gateway |-----+ +-----------+ | | +-----------------+ +-------------------+ +----------------+ | Load Balancer | | Database Server | | Web Server 1 | +-----------------+ +-------------------+ +----------------+ | | | Internal network --> +----------------------+-----------------------+--------- | | +----------------+ +----------------+ | Web Server 2 | | Web Server 3 | (more web servers) +----------------+ +----------------+ }}} == About this document == This document will describe in detail one possible method of achieving load balancing with django, including discussion on solving the "static file problem." This solution involves using the LigHTTPd web-server, FastCGI, and anywhere between two and infinity web servers. Also, a potential solution for reverse proxying using Apache and mod_python will also be discussed, but in lesser detail. Some performance numbers will be put out based on my independent study I have conducted using a variety of my own machines encompassing multiple platforms and operating systems, giving a general idea of the performance of load balancing. This document will also discuss potential pitfalls of using a load-balanced setup, how they occur and how to avoid them. It is by no means comprehensive, but usually your issues will fall into one of a few categories, most of which can be solved rather simply.