> 2010/9/23 Roberto De Ioris <[email protected]>: >> >> Il giorno 23/set/2010, alle ore 16.07, Jean-Baptiste Quenot ha scritto: > >>> 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. > > I meant average for all requests. All response times are monitored > there is no overload at all anytime. > >> 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 > > FYI I used the threading model with Flup and it is limited to > sys.maxint: See > http://trac.saddi.com/flup/browser/flup/server/threadedserver.py and > http://trac.saddi.com/flup/browser/flup/server/threadpool.py > > > Now, let's assume I have an overloaded backend, either because > application is too slow, or because there are too many connections. > > I made a test with haproxy timeout set to 10s and uwsgi harakiri at 9s. > > In the first test, application does this: > > if uri == "/": > self.startResponse("200 OK") > time.sleep(11) > return "" > >
Sorry, you have still not get the point. To reproduce the error you should put the sleep() before the accept() and this is impossibile to emulate. If you accept() one moment before the nginx timeout it will get the start_response output and the status header. Does the 29.xxx response time not looks "suspicious" to you ? By the way, i think that the only way to convince you is to show how many bytes uWSGI has sent to nginx, so wait for the "conditional logging patch" (i think i need one more day than i can release a patch). Even if you are right (and so, there is a mysterious bug in uWSGI) it will help to catch the problem :) But if i am right the real question is: "Why your not-overloaded system responds slowly ?" -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
