Dnia środa, 13 czerwca 2012 09:57:44 Roberto De Ioris pisze: > Hi, this is common problem in a lot of big-deployment setup. > > Graceful reloads are not enough when your app requires ages to reload > (this happens always for platform like rails). > > Currently the best solution is in starting a second instance (sharing the > communication socket with the old one) and shutdown the old one as soon as > the new one is ready. > > The available technics for doing that (in uWSGI) are zerg-mode (a bit > complex, but as soon as you master it you will find it unbeatable), or > having a fastrouter between your app and the webserver, routing requests > to specific instances. The fastrouter setup is simpler (and more common), > but i strongly suggest you to look at the zergpool technic: > > http://projects.unbit.it/uwsgi/wiki/ZergMode > > Another trick, is in loading the apps in lazy mode (add --lazy) then kill > one worker at time. Every new (respawned) worker will have the new copy of > the app. There is currently no option/way to make this kind of > chain-reload so you have to make some kind of script getting the pids of > the currently running workers and killing them one at time (wait for full > app loading before triggering a second kill)
I'm using FastRouter and I have some management tools written for my web stack. When I need to upgrade an app I do it on few servers at a time, and I wait until upgraded servers resubscribe to FastRouter. Łukasz Mierzwa _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
