Il giorno 10/set/2010, alle ore 11.01, Jean-Baptiste Quenot ha scritto: > 2010/9/10 Roberto De Ioris <[email protected]>: >> >> Sorry, i have re-read your first post, and i think the problem is different. >> >> If you do not see error in uwsgi log (and having disabled non-error you >> should see them) the problem is with the upper layer. If you do not see >> error in nginx log then probably the response time is so high that haproxy >> timed out. >> >> In this case you have to increase the number of workers (i think that a +2 >> should be enough for your load). > > So you mean that backlog queue is too large, while there are not > enough workers to serve all requests, and the timeout is reached.
yes > But > if uwsgi is waiting for a worker to be available, how is it possible > that the HTTP status code is correct? For example one of the URLs > always replies with a 302, while others respond with 200, and I can > see that this status code is correct in nginx logs. Because nginx will receive the complete request (it has a bigbigbig timeouts) but haproxy will timeout. > > Also, haproxy logs indicate how many sessions are currently active, > and the problem happens with a low number of active sessions. In > other words the backlog queue is not full (I had to increase it to 256 > to avoid uwsgi dropping requests). probably you have a blocking part in your app. (this could be even the db) Try adding 2 more workers, i bet on this :) > > FWIW: most of the failed requests are small: between 0 and 73 bytes. > Maybe there is a bug in nginx's uwsgi module for small responses? > Something in the nginx/wsgi stack must have changed when switching > from glup to uwsgi... > yes, flup will spawn workers on demand, so you do not have this problem. The real players are haproxy (little [but right] timeout) and uWSGI (it does not want to go non-deterministic adding new workers on demand). Nginx has not guilt :) -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
