Hi, I don't understand everything, but I agree that keep alive has a huge impact on performances.
You should compare servers which all support keep alive, or disable keep alive in the client (or disable it on all servers). In a previous job, I backported httplib and xmlrpclib to get keep alive from python 2.5 to 2.7, because HTTPS was mandotary and the handshake took between 100 and 900 ms. Our client sent 300 requests or more to load the UI. It's easy to compute the speedup of keep alive ;-) Victor Le mercredi 25 février 2015, INADA Naoki <[email protected]> a écrit : > It's not benchmark for sync vs async. It is keep-alive vs non keep-alive. > > gunicorn's default (sync) worker is designed as "backend" server. It > means it requires reverse proxy like nginx. > > Since it doesn't support keep-alive, you should use unix domain socket > when serving high req/sec. > Otherwise, "TIME_WAIT" connection fills all port. > > gunicorn supports some engines. Tornado can be used as *sync* (when > using wsgi) and keep-alive engine. > Meinheld is another option. It's very high speed server written in C. > > > On Wed, Feb 25, 2015 at 7:55 PM, Ludovic Gasc <[email protected] > <javascript:;>> wrote: > > Hi guys, > > > > I'm permitted to send you this e-mail because some people has discussed > on > > this mailing-list about AsyncIO benchmarks. > > > > I've published an improved version of my benchmarks: > > > http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-flask-and-asyncio.html > > > > Moreover, to reduce the risk to start a benchmark war in Python > community, > > this post should help: > > http://blog.gmludo.eu/2015/02/open-letter-for-sync-world.html > > > > Don't hesitate to contact me if you find an error, I'm really interested > in. > > > > Regards. > > > > -- > INADA Naoki <[email protected] <javascript:;>> >
