> Hi, > > I have a somewhat large web application that seems to take a very long > time > (~20) to start responding to http requests after I reload uwsgi by > touching > a temporary file (the "graceful restart"). I ran an strace on one of the > lagging worker processes while it was in this hanging state and it made > upwards of 10k fstat/stat() calls and 20k open() calls probing for files > related to eggs in use by my application. If I set uwsgi to start with one > worker process, it takes about 3-5 seconds for the process to start taking > requests, but if I scale it up to 10, it takes ~20 seconds for all the > processes to become ready and the system reaches a load of 6 -- there is > some serious i/o contention going on while these processes spin up. > > I recursively pre-load modules in my code after the loadapp() call in my > wsgi configuration and I suspect that this is the source of the slowdown. > Is there any way I can speed up the loading process? Alternatively, is > there a way that I can keep the worker processes around for a period of > time until the new worker processes are done loading? Is there any way to > indicate that a process is 'ready' for requests to uwsgi instead of > handing > it requests immediately? >
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) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
