Flow control implementation problems #314
Comments
|
I actually use FlowControlStreamReader for non chunked responses and FlowControlChunksQueue for chunked ones. The latter is based on FlowControlDataQueue with a few tweaks. |
|
If you want to refactor them - do it. I'll help with testing. |
|
i pushed new flow control implementation @d026a469b74cd0879ef1cab16eb54fde7fcd8be1 what is interesting it shows significant increase in performance for high IO tasks. here is test results for autobahn test suit on aiohttp 0.15.1 results for master @asvetlov @kxepal we need to run some tests @kxepal i removed |
|
@GMLudo could you run your tests for master? |
well, yes (: because it was the only way to read chunk-by-chunk chunked responses without pain. Let me check however, if FlowControlDataQueue now is able to return EOF_MARKER in place of raising EofStream error. |
|
Results looks great! Nice work! |
|
@fafhrd91 I'm preparing to go to the PyCON-US, I'll do that as soon as possible. |
|
@kxepal FlowControlChunksQueue is back |
|
@fafhrd91 thank you! all seems works perfect so far. |
|
@fafhrd91 I'm now at PyCON-US, I've just benchmarked quickly. On the pure JSON test (without DB interactions), it's clearly better, we have more or less 15% of better performances: Previous aiohttp version: Latest version: Nevertheless, with pgsql benchmark, I've almost the same value, but I think the bottleneck isn't in aiohttp. Thanks for this improvement, when you release a new version of |
|
@GMLudo could you run tests again. i added bunch of optimizations in @91f63992dbaabc8bf89cf17b100d1d15ad37322c but make some changes to server code:
what is interesting is 10x difference with sync frameworks, on my local machine i see about 30% difference only. |
If I understand correctly your remark, to my knowledge, TCP keep-alive and HTTP keep-alive are two different things. Web seems to be agree with me: http://stackoverflow.com/questions/9334401/http-keep-alive-and-tcp-keep-alive
Ok, like you did in #330.
Yes, I use API-Hour for that: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/API-Hour/hello/etc/hello/api_hour/gunicorn_conf.py#L6
I don't understand this part of this sentence, how you find
To my experience, micro-benchmarks results != macro-benchmarks results, I had a lot of examples like with AsyncIO and aiouv. Theoretically, aiouv should be really faster that the standard AsyncIO loop, but finally, not a big change in a macro-benchmark. But, maybe I've missed something or I've made a mistake. |
regarding 10x, here is text from your email from asyncio mailing list: |
|
|
BTW, thanks a lot for theses optimizations. |
|
|
in general, asyncio timers are very expensive. |
|
I've just benchmarked in the same conditions that previous benchmark. It's really better (almost x2), but not the big improvement as you told me: Maybe, I've missed something, I've did theses changes: @@ -39,8 +39,8 @@ class Container(api_hour.Container):
def make_servers(self):
return [self.servers['http'].make_handler(logger=self.worker.log,
debug=self.worker.cfg.debug,
- keep_alive=self.worker.cfg.keepalive,
- access_log=self.worker.log.access_log,
+ keep_alive=0,
+ access_log=None,
access_log_format=self.worker.cfg.access_log_format),
servers.yocto_http.YoctoHttpJson,
servers.yocto_http.YoctoHttpText]
Any clue to track the difference between your setup and my setup ? |
|
here is my aiohttp script: import asyncio
import json
from aiohttp import web
def index(req):
return web.Response(
body=json.dumps({'message':'Hello, World!'}).encode('utf-8'))
yield from ()
@asyncio.coroutine
def init(loop):
app = web.Application(loop=loop)
app.router.add_route('GET', '/json', index)
handler = app.make_handler(keep_alive=0)
srv = yield from loop.create_server(handler, '0.0.0.0', 8080)
print("Server started at http://127.0.0.1:8080")
return srv, handler
loop = asyncio.get_event_loop()
srv, handler = loop.run_until_complete(init(loop))
def main():
try:
loop.run_forever()
except KeyboardInterrupt:
loop.run_until_complete(handler.finish_connections())
main()i run it in one process. i use pyramid for testing wsgi, i explicitly set number of gunicorn workers to 1. |
|
Ok, it makes sense. Moreover, Pyramid is really slower compare to WSGI raw implementation, you can check the preliminary round 10 results of TechEmpower benchmarks (WARNING: This URL is normally semi-private, because they don't finish to validate all results for all frameworks. Don't share this URL). Nevertheless, for JSON test with Python, the results seem to be correct: http://www.techempower.com/benchmarks/previews/round10/#section=data-r10&hw=peak&test=json&l=1kw ) It isn't always a correct shortcut, but at least here, if I use a proportional rule between your results, my results, and TechEmpower results, we have more or less the same proportional rate. Thank your for theses improvements, I'll integrate that in TechEmpower benchmark when the new release of aiohttp will be available. |
|
ok, that makes sense |
|
i guess we are done with optimizations :) |
|
@fafhrd91 Yes, indeed ;-) |
current implementation can not really control flow, i think flow control code needs to be part of FlowControlXXX classes.
@kxepal do you use FlowControlStreamReader or FlowControlDataQueue in your projects?
The text was updated successfully, but these errors were encountered: