-
-
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
refactor: Extract zlib-related logic into a single module #7223
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7223 +/- ##
==========================================
- Coverage 97.33% 97.31% -0.03%
==========================================
Files 106 107 +1
Lines 31309 31352 +43
Branches 3891 3901 +10
==========================================
+ Hits 30476 30511 +35
- Misses 634 640 +6
- Partials 199 201 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
Backport to 3.9: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply 3ff81dc on top of patchback/backports/3.9/3ff81dc9c9ce20efd3bf54cf52adaf438c483a92/pr-7223 Backporting merged PR #7223 into master
🤖 @patchback |
@Dreamsorcerer Thanks for checking and fine-tuning the PR. I appreciate your help |
Thanks a lot. If you could handle the backport as well, that'd be great. |
<!-- Thank you for your contribution! --> Addresses issue #7192 Refactors the logic to have the zlib-related stuff concentrated into a single module No #7192 - [x] I think the code is well written - [x] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Sam Bull <[email protected]> (cherry picked from commit 3ff81dc)
) <!-- Thank you for your contribution! --> Backport #7223 Addresses issue #7192 Refactors the logic to have the zlib-related stuff concentrated into a single module No #7192 - [x] I think the code is well written - [x] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Sam Bull <[email protected]> (cherry picked from commit 3ff81dc) <!-- Thank you for your contribution! --> ## What do these changes do? <!-- Please give a short brief about these changes. --> ## Are there changes in behavior for the user? <!-- Outline any notable behaviour for the end users. --> ## Related issue number <!-- Are there any issues opened that will be resolved by merging this change? --> ## Checklist - [ ] I think the code is well written - [ ] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." --------- Co-authored-by: Mykola Mokhnach <[email protected]>
…n changes (#7797) <!-- Thank you for your contribution! --> ## What do these changes do? Changes the threshold that is required to compress in the executor for websocket messages to 5KiB #7223 changed the websocket implementation to compress messages > 1KiB in the executor. The threshold was a bit low which caused an increase in latency compressing messages as the overhead to use the executor can exceed the cost to compress tiny messages. When testing 3.9.0 with Home Assistant, we saw a 3 order of magnitude increase in executor usage which resulted in an overall increase in cpu time since all the tiny messages were being compressed in the executor. I could not find the motivation for choosing 1KiB in the original PR ## Are there changes in behavior for the user? <!-- Outline any notable behaviour for the end users. --> ## Related issue number <!-- Are there any issues opened that will be resolved by merging this change? --> ## Checklist - [x] I think the code is well written - [ ] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."
…n changes (#7797) <!-- Thank you for your contribution! --> ## What do these changes do? Changes the threshold that is required to compress in the executor for websocket messages to 5KiB #7223 changed the websocket implementation to compress messages > 1KiB in the executor. The threshold was a bit low which caused an increase in latency compressing messages as the overhead to use the executor can exceed the cost to compress tiny messages. When testing 3.9.0 with Home Assistant, we saw a 3 order of magnitude increase in executor usage which resulted in an overall increase in cpu time since all the tiny messages were being compressed in the executor. I could not find the motivation for choosing 1KiB in the original PR ## Are there changes in behavior for the user? <!-- Outline any notable behaviour for the end users. --> ## Related issue number <!-- Are there any issues opened that will be resolved by merging this change? --> ## Checklist - [x] I think the code is well written - [ ] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." (cherry picked from commit 27c308b)
…messages from websocket compression changes (#7799) **This is a backport of PR #7797 as merged into master (27c308b).** <!-- Thank you for your contribution! --> ## What do these changes do? Changes the threshold that is required to compress in the executor for websocket messages to 5KiB #7223 changed the websocket implementation to compress messages > 1KiB in the executor. The threshold was a bit low which caused an increase in latency compressing messages as the overhead to use the executor can exceed the cost to compress tiny messages. When testing 3.9.0 with Home Assistant, we saw a 3 order of magnitude increase in executor usage which resulted in an overall increase in cpu time since all the tiny messages were being compressed in the executor. I could not find the motivation for choosing 1KiB in the original PR ## Are there changes in behavior for the user? <!-- Outline any notable behaviour for the end users. --> ## Related issue number <!-- Are there any issues opened that will be resolved by merging this change? --> ## Checklist - [x] I think the code is well written - [ ] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." Co-authored-by: J. Nick Koston <[email protected]>
…h small messages from websocket compression changes (aio-libs#7799) **This is a backport of PR aio-libs#7797 as merged into master (27c308b).** <!-- Thank you for your contribution! --> Changes the threshold that is required to compress in the executor for websocket messages to 5KiB aio-libs#7223 changed the websocket implementation to compress messages > 1KiB in the executor. The threshold was a bit low which caused an increase in latency compressing messages as the overhead to use the executor can exceed the cost to compress tiny messages. When testing 3.9.0 with Home Assistant, we saw a 3 order of magnitude increase in executor usage which resulted in an overall increase in cpu time since all the tiny messages were being compressed in the executor. I could not find the motivation for choosing 1KiB in the original PR <!-- Outline any notable behaviour for the end users. --> <!-- Are there any issues opened that will be resolved by merging this change? --> - [x] I think the code is well written - [ ] Unit tests for the changes exist - [ ] Documentation reflects the changes - [ ] If you provide code modification, please add yourself to `CONTRIBUTORS.txt` * The format is <Name> <Surname>. * Please keep alphabetical order, the file is sorted by names. - [ ] Add a new news fragment into the `CHANGES` folder * name it `<issue_id>.<type>` for example (588.bugfix) * if you don't have an `issue_id` change it to the pr id after creating the pr * ensure type is one of the following: * `.feature`: Signifying a new feature. * `.bugfix`: Signifying a bug fix. * `.doc`: Signifying a documentation improvement. * `.removal`: Signifying a deprecation or removal of public API. * `.misc`: A ticket has been closed, but it is not of interest to users. * Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files." Co-authored-by: J. Nick Koston <[email protected]>
What do these changes do?
Addresses issue #7192
Refactors the logic to have the zlib-related stuff concentrated into a single module
Are there changes in behavior for the user?
No
Related issue number
#7192
Checklist
CONTRIBUTORS.txt
CHANGES
folder<issue_id>.<type>
for example (588.bugfix)issue_id
change it to the pr id after creating the pr.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.