Il giorno 23/set/2010, alle ore 16.07, Jean-Baptiste Quenot ha scritto: > 2010/9/23 Roberto De Ioris <[email protected]>: >> >> > > 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.
No, harakiri starts after accept() there is nothing wrong with your code, i am suggesting you a way to avoid maintaing more workers (that is the solution to your problem). Simply uWSGI has no resource to accept() in time (but it accepts just before nginx timeout, and just in time to send headers, this is why when i always see 29.XXX on empty response i say "bingo"). This is how the whole stack works. > 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). > average ? the rate of bad response (empty) is so little that i really have doubt that it can be accounted in the average. You have little times when the workers are overloaded, no one can respond in a reasonable time. > 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. ...and keep in mind that i have explained to you that flup dinamically spawns workers :) If you have always a worker to accept() a request the problem goes away. But i do not want to suggest people blindly adding workers. It is a wrong approach, after a N number of workers, system performance per-request will degrade. > 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. i know (and i trust you), and this is the expected behaviour. No dynamic resource allocation. The sysadmin must know in advance what to allocate. > > 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. Why not ? The socket is by-server it is not shared in your cluster, a node can became stale for a couple of nanoseconds, and you (haproxy) lost a request because uWSGI has responded after years :). If you see the time of the request in the nginx logs you posted you will see how they are in the same amount of time: Sep 23 11:40:07 Sep 23 11:40:10 Sep 23 11:40:35 Sep 23 11:40:49 (OT: is it normal that they came from the same ip ?) The matter is all on how uWSGI and flup manages workers, if you want to have a similar result of Flup, spawn 50 workers http://trac.saddi.com/flup/browser/flup/server/preforkserver.py It is the default maximum of flup Obviously it is a total foolish value and you risk to destroy your server, so measure carefully the maximum value your machine can support. I hope this test do not push your site offline :P Sorry if i sound "raw", but i understand that something that is clear for me cannot be clear for someone else. The main problem was that (i tought) there is no way to have the confirmation of timeouts/problems between the connect() and accept() but the folks at nginx lists give me the right tool for the job (and i bet the new logging variable is amazing for you even if you will switch back to flup) -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
