HTTP pipelining support improvements

[telendt]

Request handling in ServerHttpProtocol implementation executes handle_request coroutines sequentially when HTTP pipelining is used.

Please take a look at the following gist for more details:
https://gist.github.com/telendt/7732021

There are 2 HTTP requests for 2 different resources, each one is available after 1s (I use the asyncio.sleep here, but it can be really some IO happening there). These coroutines might run concurrently (the second one starts when the previous one "waits"), but they run sequentially instead (the second one starts when the previous one terminates).

Of course concurrent execution of handle_requests coroutines would still need to return responses to those requests in the same order that the requests were received. In that case HttpMessage shouldn't write to the transport directly (except of the one from the first pending coroutine) but would need to write to some buffer instead.

[fafhrd91]

wont fix for now

[ludovic-gasc]

Hi @fafhrd91,

I'm looking for why aiohttp.web+API-Hour is slow compare to others Web frameworks for the plaintext test in FrameworkBenchmarks: https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=plaintext&l=1kw

In fact, in this test, they use HTTP pipelining as described in this issue.

Personally, I don't use this feature on production.
For only one benchmark test, it isn't critical to improve that, it's only for your information.
Moreover, I already have an alternative solution to improve that for round 11.

Regards.

[fafhrd91]

to implement pipelining we would need to introduce write buffer, and that would reduce normal performance. i'm not very interested in plain text performance improvements, my last optimization that gives 50-70% increase of raw performance only gives about 2-3% performance increase in real production systems.

[ludovic-gasc]

my last optimization that gives 50-70% increase of raw performance only gives about 2-3% performance increase in real production systems.

@fafhrd91: Interesting, I've better numbers based on benchmark suite. I'll check statistics on our HAproxy frontends to confirm or invalidate your observations when we'll upgrade our daemons. Nevertheless, maybe you have more CPU-bound tasks than me in your endpoints. Or maybe you have a bigger bottleneck than aiohttp itself.

[telendt]

to implement pipelining we would need to introduce write buffer, and that would reduce normal performance

Not if the write buffer is only used when needed (if there are any previous pending requests of the same connection). Pipelining could also be enabled/disabled with some protocol level settings. Finally, there could be some configurable "strategies" (when to allow and forbid pipelining).

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.