Skip to content
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

Merged
merged 10 commits into from
Dec 22, 2023

Conversation

pgarg66
Copy link
Contributor

@pgarg66 pgarg66 commented Dec 21, 2023

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 #

Copy link

codecov bot commented Dec 21, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (6f0133b) 81.8% compared to head (5b29cb6) 81.8%.
Report is 37 commits behind head on master.

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     

@pgarg66 pgarg66 marked this pull request as ready for review December 21, 2023 21:50
Copy link
Contributor

@lijunwangs lijunwangs left a 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.

@pgarg66 pgarg66 added v1.16 PRs that should be backported to v1.16 v1.17 PRs that should be backported to v1.17 labels Dec 22, 2023
Copy link
Contributor

mergify bot commented Dec 22, 2023

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.

@pgarg66 pgarg66 merged commit 6bbd366 into solana-labs:master Dec 22, 2023
37 checks passed
Copy link
Contributor

mergify bot commented Dec 22, 2023

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.

mergify bot pushed a commit that referenced this pull request Dec 22, 2023
* 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)
mergify bot pushed a commit that referenced this pull request Dec 22, 2023
* 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;
Copy link
Contributor

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?

Copy link
Contributor Author

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().

streamer/src/nonblocking/quic.rs Show resolved Hide resolved
streamer/src/nonblocking/quic.rs Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1.16 PRs that should be backported to v1.16 v1.17 PRs that should be backported to v1.17
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants