Hi Łukasz, On Mon, 21 Jan 2013 14:41:34 +0100 Łukasz Mierzwa <[email protected]> wrote:
> 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. In practise you can only do those things when worker gets actually some traffic. You can look at this approach from a different perspective: currently uWSGI allows you to use lots of different algos (and if there's none you can write your own) to dynamically spawn the right amount of workers to handle current traffic. Maybe much easier approach to address this problem is to ask the question: "how long do you want to keep worker idle" which does not require sophisticated algorithms to achieve the same goal. This is just slightly more sophisticated version of 'idle' option, nothing more. > 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. I would consider it as a hack where you cannot where you are vulnerable to race condition between getting information and killing the worker. > 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. I call it "expensive" due to extra initialization which usually takes place at the beginning (at least in our code) otherwise it would take place on the 1st request. > 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. This is what I'm going to try as well (cheaper_busyness). Marcin _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
