Why would You need to care about worker age? You can already respawn it if it eats too much memory, the max-requests option is just another way of protecting from memory leaks (a more paranoid one), and it's the memory leaks/usage is the only thing You should really care about. If app does some weird things that make worker lifetime important, than it it's the app logic that should take care of tracking it. AFAIK You can access workers stats from uWSGI API (including startup time) and do whatever is needed once worker was running too long.
> Well, spawning a worker is an expensive task whereas cheaping them > out (as name suggests) is cheap - that why in some cases keeping > them around might be handy.. but then you are facing other > problems :-) This is only true if Your app runs some post fork() code, like reconnecting to db or such. fork() alone is not very expensive, unless You call it several time every second. Keeping workers around is very good thing when You want to reduce response time latency, if avg response time is 500ms than it means that every request might need to wait up to 500ms in backlog queue if it is dispatched to busy worker. So You should keep more workers to always have one that is idle and ready to accept new requests. This is very easy to show with cheaper_busyness, just change busyness limits so that uWSGI will keep different amount of workers and watch Your app avg response times go up or down. -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
