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. 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. 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). 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... -- Jean-Baptiste Quenot _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
