2010/9/23 Roberto De Ioris <[email protected]>: > > As i have said, uWSGI is responding to connection request (so the time > between connect() and accept()) > very slowly, your response time are all near 30 (29.xxx) > but no so slow to timeout nginx. How to solve this ? > > This is hard to answer, adding another couple of workers could solve the > problem, but the rate of error > request is so little that consuming more memory or cpu resource could not be > a good idea. > > Check if there are slow part of your code that can be managed by grunt > processes instead of workers. > Pratically when a request is potentially slow you can detach it from the pool > and spawn another worker while the old > request continue its job. (good candidates are image processing code, big > queries and connection to external servers)
I don't understand your explanation. If my code was at fault, it would be killed by harakiri often, but this is not the case. If I had connection bursts so that the delay between connect() and accept() would get longer, my server would have very slow average response times, but this is not the case, the average response time is 400ms 24 hours a day, and I don't have a lot of concurrent connections (about 15 in average). Also, keep in mind that even if Flup was not performing as good as uwsgi before I switched, I had no request at all failing like this. Believe me because I receive an email alert everytime a request is aborted or times out :-) The problem suddenly appeared when I switched to uwsgi. And last but not least, empty responses appear in a not so random way. For example, one of my servers did not reply any empty response since yesterday evening, while another one did. As traffic is evenly distributed and the applications configured in the same way, there is no good reason why one server would fail and not the other. So please double check on your side if something could go wrong, an edge case or something. If you spot a particular section in the code I renew my offer to set a gdb breakpoint in production. -- Jean-Baptiste Quenot _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
