-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve performance of WebSockets when there is no timeout #8660
Conversation
The common case for WebSockets is to call receive without a timeout, or use the WebSocketResponse as an async iterator. The read was always wrapped with an async timeout even if the timeout was not used which accounted for as much as 50% of the run time each loop. If there is no timeout, avoid wrapping the read call in the context manager which creates a new Timeout() object each time.
This should significantly help |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #8660 +/- ##
=======================================
Coverage 97.97% 97.97%
=======================================
Files 107 107
Lines 33780 33786 +6
Branches 3966 3968 +2
=======================================
+ Hits 33096 33102 +6
Misses 507 507
Partials 177 177
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I wonder if there's a way to improve the timeout version too... |
Nothing obvious stands out in https://github.com/python/cpython/blob/2f5c3b09e45798a18d60841d04a165fb062be666/Lib/asyncio/timeouts.py#L85 but I also haven't stared at it long enough. |
Thanks! |
Backport to 3.10: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply 14d5295 on top of patchback/backports/3.10/14d52957290e88748f37ed396c68a23d13a7ecda/pr-8660 Backporting merged PR #8660 into master
🤖 @patchback |
Backport to 3.11: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply 14d5295 on top of patchback/backports/3.11/14d52957290e88748f37ed396c68a23d13a7ecda/pr-8660 Backporting merged PR #8660 into master
🤖 @patchback |
(cherry picked from commit 14d5295)
(cherry picked from commit 14d5295)
…hen there is no timeout (#8663)
…hen there is no timeout (#8664)
Found a way to make it faster python/cpython#122882 |
What do these changes do?
The common case for WebSockets is to call receive without a timeout, or use the WebSocketResponse as an async iterator. The read was always wrapped with an async timeout even if the timeout was not used which accounted for as much as 50% of the run time each loop. If there is no timeout, avoid wrapping the read call in the context manager which creates a new Timeout() object each time.
Are there changes in behavior for the user?
Performance improvement
related reading https://www.researchgate.net/publication/348993267_An_Analysis_of_the_Performance_of_Websockets_in_Various_Programming_Languages_and_Libraries
Is it a substantial burden for the maintainers to support this?
no
before
after