-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Throttle unstaked quic streams for a given connection #34562
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #34562 +/- ##
=======================================
Coverage 81.8% 81.8%
=======================================
Files 820 820
Lines 221055 221094 +39
=======================================
+ Hits 180887 180980 +93
+ Misses 40168 40114 -54 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes looks good for me as the first rate limiter implementation.
Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. |
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* Throttle unstaked quic streams for a given connection * Fix interval duration check * move wait to handle_chunk * set max unistreams to 0 * drop new streams * cleanup * some more cleanup * fix tests * update test and stop code * fix bench-tps (cherry picked from commit 6bbd366)
* Throttle unstaked quic streams for a given connection * Fix interval duration check * move wait to handle_chunk * set max unistreams to 0 * drop new streams * cleanup * some more cleanup * fix tests * update test and stop code * fix bench-tps (cherry picked from commit 6bbd366)
@@ -182,7 +182,9 @@ mod tests { | |||
let num_bytes = PACKET_DATA_SIZE; | |||
let num_expected_packets: usize = 3000; | |||
let packets = vec![vec![0u8; PACKET_DATA_SIZE]; num_expected_packets]; | |||
assert!(client.send_data_batch(&packets).await.is_ok()); | |||
for packet in packets { | |||
let _ = client.send_data(&packet).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was the assertion dropped intentionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the send_data can return error. So we can't assert on is_ok()
.
Problem
We currently limit of concurrent unstaked QUIC streams. But the client can create unbounded number of streams over time by closing existing streams and creating new ones.
Summary of Changes
Track number of streams created in a connection
Once the limit is reached, wait till the next time interval before accepting new streams
Fixes #