In terms of commercial options, we have sometimes gone with ZXTM (now known as StingRay Traffic Manager) , it has some truly amazing features and you should definitely check it out. I believe that RiverBed have since started issuing free commercial licences for up to a certain traffic rate, and it's a downloadable package/virtual appliance.
We also often use the load balancers that come with Rackspace Cloud, they have proven to be quite efficient. When using this route, we also tend to throw everything in front of CloudFlare too (if you haven't seen this already, check it out. It is free for non SSL usage too!)
In a nut shell;
* ZXTM - commercial (free licence to a certain amount), amazing traffic script language, self hosted
* Rackspace Cloud - does what it says on the tin, no traffic scripting
* F5 - commercial, not had any personal experience with it (but one of our providers uses it as a shared load balancer for their customers and it's been stable)
* haproxy - works, but it can be a pita!
* CloudFlare - this isn't a load balancer, but does give you much better control over DNS (it proxies your site, and effectively makes 'DNS changes' instant)
I believe uWSGI has some really good load balancing features too, but I haven't used them in too much depth yet (despite being an avid user of uWSGI for 2-3 years!)
Hope this helps
Cal
On Tue, Oct 30, 2012 at 8:14 AM, Kurtis Mullins <kurtis.mullins@gmail.com> wrote:
The easiest thing I've found to use is simply uWSGI with Nginx. It's easy to just create new Django servers on the fly. You simply include the IPs in a list and it will use various algorithms (optional) to distribute the requests appropriately.As a lot of applications are IO bound, you could also use a distributed database system to help with your scalability. I don't have much experience in that area, though.This still leaves a point of failure: Nginx (or whatever load balancer or reverse proxy you use). Maybe someone else here will know more about load balancing Nginx itself ... that might require specialized hardware. I know a lot of cloud services offer load balancers (e.g. rackspace) so you could possibly use that with multiple nginx servers and further multiple django servers.
On Tue, Oct 30, 2012 at 3:42 AM, Isaac XXX <vyrphan@gmail.com> wrote:Hi there,
maybe you're right, but I'm not really worried about RAM footprint, or resources consumption. I'm concerned now on architecture, setting a right scalable system, and a right cluster of systems, without lacks of communications between them.
Underlaying technologies can be easily replaced (say apache-mod_wsgi for gunicorn or uwsgi), and some performance improvements can be made, but this is not what I'm looking for. I'm looking for the tools to generate a robust system, balancing requests through several systems, and allowing increase the size of this system (adding more servers) without trouble.
Cheers,
Isaac
On 10/29/2012 05:18 PM, Some Developer wrote:
On 29/10/2012 16:03, Isaac XXX wrote:
Hi there,
thank you for response Tom.
Actually, I've a complete idea at how to build this system, but I lack the exact information about how to join systems, and what I was looking for was a source of cohesive information on all systems. At least, when I finish to build that system, I will write this tutorial.
For someone who can help me, I will describe here what I thought it can be this structure:
- 1 nginx, as a reverse proxy on frontend, serving static/media and redirecting content to apache clusters
- n apache servers, with mod_wsgi, serving dynamic data
- m postgresql servers, in a master-slave flavour
Cheers,
Isaac
Why not just ditch Apache entirely and just use Nginx for serving all media (both static and dynamic)? You can then save quite a few resources as you only need to run one HTTP server rather than two.
Using Nginx to serve Django content works well. Just serve your Django application via FastCGI or uWSGI and you'll significantly simplify your configuration and reduce RAM usage on your servers as well.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment