> Roberto De Ioris <roberto@...> writes:
>> What happens if you add
>>
>> lazy = true
>>
>> to your config ?
>
> It works, that's what happens. :) Responds to requests, and the first
> outside
> request returns in 67 milliseconds according to curl -w '%{time_total}'.
> Cool!
>ok, so there is some uninitialized part before fork() i need to check. --lazy instruct your app to be loaded only after worker spawn. > Two questions on how effective this prewarming is: > > a) while a worker is reloading (e.g. due to max-requests or reload-on-rss) > does > uwsgi master know to issue requests only to other workers, so that no > request > in that instance is delayed waiting for the reloading worker? yes, reloading worker will not be able to accept() requests, while the others (healthy) will be able to. > > b) while entire instance is reloading (e.g. due to SIGHUP), does uwsgi > notify > the downstream webserver/load-balancer of the start and end of the reload, > so > that the load-balancer can prefer its other upstreams while this one > reloads? no, if your load-balancer uses round-robin it will connect to the reloading instance and will wait until it is ready. But maybe you can "mask" this behavior using the "zerg dance" (i posted it in the previous mail) where you start a second instance before shutting down the first. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
