Hi Roberto, On Thu, 10 Jan 2013 13:23:54 +0100 "Roberto De Ioris" <[email protected]> wrote:
> > > We've recently migrated from Apache which does round-robin > > distribution to its workers to uWSGI which does it on a > > first-worker-not-busy basis. > > ??? > > apache (as the vast majority of preforking daemons) works in the same > way as uWSGI, there is a shared socket on which various > processes/threads wait() and accept(). The only solution using round > robin is passenger so i suppose you are referring to it ? Well, I've done some testing and looks like Apache2 is distributing requests in round robin fashion (I was looking at pids handling consequtive static requests). From what I could see it uses poll (as opposite to epoll for uWSGI on Linux). I wrote a simple program which bind to socket in parent and accept connections in children who inherited socket from parent. Connections were accepted in round-robin fashion (although that was done in blocking mode). What's special about uWSGI in this respect ? epoll or maybe something else ? > > Some parts of our application cache things per-child assuming that > > that cache isn't going to live for very long, since we have a max > > request limit per child (implemented with childs doing harakiri) > > under Apache any given worker wouldn't live for more than 5-10m. > > --max-requests is the equivalent of apache MaxRequestPerChild I recall the other day we spoke about --idle option: maybe it would be possible to implement it on per-worker basis rather than on per-instance (all workers) basis ? > > But under uWSGI it's possible to have a server with say 16 child > > procceses, where normally only the first 8 serve requests. > > if this is the standard state, well you are spawning too much > processes :) 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 :-) Marcin _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
