> I'm not sure what makes more sense: > > 1. managing a separate uwsgi master process + processes for each of the > 3+ apps > 2. using an emperor process handle the 3+ apps > >the broodloord/zerg stuff looks really interesting, and like it might benefit >us a lot. but that would >mean switching from the command-line version to the > file based config -- and that will be a >chunk of devops time.
I can't comment on the emperor option as I have not tried that yet. We have a production stack similar to your original and I have recently been developing a custom patching deployment setup to create zero down time with no connection losses in almost all server updates (new python code, new, nginx conf, new uwsgi ini and new uwsgi code). I originally was using Zerg mode for that, but ran into a number of issues (previously sent in this mailing list). Instead now I run two master processes and can page flip between them and use the SIGTSTP to gracefully stop each of them. You can scale that to N applications with a little config work. Emperor ideally would make that unnecessary, but you'd have to try or see what others say about it. One difference in our stack from yours is that we use Supervisor to manage all the processes (nginx, two mongos procecesses and two uwsgi masters). Makes it easy to add more processes and gets rid of your command line issue pretty easily, I think. Part of the patching system is a remote update python util that can do graceful reloads across a set of servers at once. If I had your 3+ app setup I would set up paired masters for each so that I could do graceful reloads on a single app or the whole stack depending on what had changed. My two pesos semi custom to our stack, but hope its useful. _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
