With nginx you could get simple load balancing capabilities plus
performance increased in conjunction with uwsgi, just configuring an
upstream with all of your servers an then using it on the proxy_pass(for
whatever server you want, ie gunicorn, apache,tomcat) or uwsgi_pass(if you
use uwsgi as a wsgi server for your django apps).
In fact I think that Zato itself should consider to move in this direction
taking performance into account, this reduce the need of software
components running, since:
1- nginx can serve static files for django zato-webadmin,
2- nginx can talk to unix sockets so local servers can be deployed without
having to open ports
3- nginx have native support for uwsgi using a binary protocol
4- uwsgi seems to have better performance than gunicorn in the last versions
5- uwsgi can serve many differents wsgi apps with only one running instance
running as Emperor, this can be used to serve servers app and also django
6- nginx loadbalancer can be substitute haproxy in this terms
this is just a few ideas, to improve the performance of Zato
On Mon, Jan 27, 2014 at 11:12 AM, Dariusz Suchojad firstname.lastname@example.org wrote:
On 01/27/2014 03:35 PM, Axel Mendoza Pupo wrote:
In my opinion you should deploy your django apps with nginx + uwsgi or
nginx + gunicorn. Zato is not intended to do so since it’s an ESB, you
could use it to develop apps but not for django, just for Zato as
Well, you know, the load-balancer is an embedded HAProxy instance so
there’s nothing really preventing anyone from using it for other
purposes as well.
There wouldn’t be much support from Zato as such but still, HAProxy is
precisely meant to distribute the traffic across servers so as long as
one doesn’t interfere with Zato’s own configuration they should be ready
to use the LB as is. In HAProxy terms, you just need to use different
frontends and backends.
Here’s a link to a discussion regarding log formats in HAProxy.
But just to make sure, one would simply be using HAProxy at that point
merely taking advantage of the fact that its configuration can be
updated remotely using the source code view.
So I wouldn’t reject the idea as long as we understood this is just
making use of a convenient fact that HAProxy is already there.