-
Notifications
You must be signed in to change notification settings - Fork 290
Set a limit on max number of concurrent outbound http requests #3285
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
base: main
Are you sure you want to change the base?
Conversation
It just occured to me how we could limit actual connections instead of requests: struct PermittedTcpStream {
inner: TcpStream,
permit: OwnedSemaphorePermit,
}
// simple wrappers just like our existing `RustlsStream`
impl AsyncRead for PermittedTcpStream { ... }
impl AsyncWrite for PermittedTcpStream { ... } The permit would be acquired out in |
f20022c
to
d9fab0e
Compare
Signed-off-by: Ryan Levick <[email protected]>
Signed-off-by: Ryan Levick <[email protected]>
d9fab0e
to
68e5471
Compare
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.
LGTM, thanks!
// Permit count is the max concurrent connections + 1. | ||
// i.e., 0 concurrent connections means 1 total connection. | ||
.map(|n| Arc::new(Semaphore::new(n + 1))), |
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.
Not a huge deal since we're talking about rather large limits but I don't understand this interpretation. I would expect "0 concurrent connections" to mean "you can't ever connect" (which should perhaps be invalid).
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.
I guess I have a different interpretation. A concurrent request is by definition one that is happening during another request. 0 concurrent requests would therefore mean "no requests happening at the same time" not "no requests at all". I think we should just pick which ever interpretation is most convenient and use that.
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.
How many requests are involved in "2 concurrent requests"?
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.
A concurrent request is by definition one that is happening during another request
That is strictly true, but I think that doing the +1 makes everything else more confusing. The first request becomes concurrent once there is two total requests.
I'd vote for removing the + 1
// If we're limiting concurrent outbound requests, acquire a permit | ||
let permit = match self.concurrent_outbound_connections_semaphore { | ||
Some(s) => s.acquire_owned().await.ok().map(Arc::new), | ||
None => None, | ||
}; |
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.
I think this needs to be moved down into ConnectOptions::connect_tcp
or it will still be limiting requests instead of connections.
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.
Ah yea of course!
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.
Should be good now: a472018
Signed-off-by: Ryan Levick <[email protected]>
Fixes #3281
Wraps outbound requests in a semaphore with configurable permit size. This allows runtime config to decide how many outbound requests may be made at a give time.