To avoid TIME_WAIT, I used "sudo sysctl -w tcp_tw_recycle=1" command.
About Meinheld, I've tested a little bit in the past. From my little tests, yes it improves performance, but not at the same level as aiohttp+API-Hour version. Moreover, to my knowledge, almost nobody use that on production, contrary to Gunicorn. The goal was to compare the standard production setup, as explained in Django and Flask documentation, with aiohttp.web+API-Hour. To be honest, for me, Meinheld uses a little bit black magic to try to transform sync code to async, I don't recommend that on production for a complex Web application. -- Ludovic Gasc On Wed, Feb 25, 2015 at 4:20 PM, INADA Naoki <songofaca...@gmail.com> wrote: > 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 <gml...@gmail.com> 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 <songofaca...@gmail.com> >
