On Wed, Feb 25, 2015 at 7:49 PM, INADA Naoki <[email protected]> wrote:
> On Thu, Feb 26, 2015 at 1:33 AM, Ludovic Gasc <[email protected]> wrote: > > To avoid TIME_WAIT, I used "sudo sysctl -w tcp_tw_recycle=1" command. > > It avoid TIME_WAIT problem. > But difference between keep-alive and non keep-alive is very huge > although tcp_tw_recycle=1. > I'm not agree with you, in fact I've used two others commands in a boot script: echo -n 1 > /proc/sys/net/ipv4/tcp_tw_recycle echo -n 1 > /proc/sys/net/ipv4/tcp_tw_reuse I don't remember all parameters I've optimized, because I did a lot tries/errors on my benchmark labo since one year. I'm checking to push missing parameters in the benchmarks repository. Without theses parameters, you're right, it's catastrophic for Django/Flask, 50-100 HTTP queries by second. Thanks for the keep-alive catch, I thought aiohttp.server hadn't keepalive enabled by default, in fact, it changed recently: http://aiohttp.readthedocs.org/en/latest/changes.html#id4 - Server has 75 seconds keepalive timeout now, was non-keepalive by default. I've disabled keep_alive in api_hour, I quickly tested on agents list webservices via localhost, I've 3334.52 req/s instead of 4179 req/s, 0.233 latency average instead of 0.098 and 884 errors instead of 0 errors. It isn't a big change compare to others Web frameworks values, but it's a change. To rerun everything I need time: I've a full-time job and a family, I'll rerun that this week-end. > > > 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. > > I admit that meinheld is not used well. > But I think you should use some engine supporting keep-alive to > compare with aiohttp. > > How about using nginx for both of aiohttp and sync server? > > wrk -(HTTP on TCP)-> nginx -(uwsgi on unix socket w/o keep-alive)-> uWSGI > wrk -(HTTP on TCP)-> nginx -(HTTP on unix socket w/ keep-alive)-> > Gunicorn (Tornado worker) > wrk -(HTTP on TCP)-> nginx -(HTTP on unix socket w/ keep-alive)-> aiohttp > > Or how about don't use keep-alive on aiohttp? > It's easier to me to rerun without keep-alive enabled. I'll do a test this week-end with nginx to see if I've a big change. Certainly less errors but certainly more latency. About a more realist scenario, the Empower Framework Benchmark will be more interesting than my benchmark on a kitchen table. I've published that to conterbalance some bias about AsyncIO. > > > > > 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. > > Meinheld's async feature is based on greenlet (like gevent). > But you can use meinheld without using async API. > It can be high performance sync server supporting keep-alive. > First, I will test with nginx before meinheld, nginx is more frequent in Python webdev toolbox. > > -- > INADA Naoki <[email protected]> >
