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

Add scaffolding for pool throttling #2667

Merged
merged 14 commits into from
Jul 15, 2024

Conversation

mdaigle
Copy link
Contributor

@mdaigle mdaigle commented Jul 11, 2024

This adds a mechanism for throttling enforcement within the connection pool. Basic passthrough and concurrency limiters are included. Focusing on the high throughput case (no rate limit), so I will add a backlog work item to implement the pool blocking period rate limiter.

}
}

private bool IsBlockingPeriodEnabled()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

carried over verbatim from DbConnectionPool

@@ -40,14 +36,10 @@ protected override SqlConnectionX CreateDbConnection()

internal SqlDataSource(
SqlConnectionStringBuilder connectionStringBuilder,
SqlCredential credential,
RemoteCertificateValidationCallback userCertificateValidationCallback,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removing these for now until we fully implement additional auth pathways

Copy link
Contributor

@benrr101 benrr101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly nit changes, but let me get back to you about the delegate stuff. I'm not convinced we can't do that with less overhead.

/// <param name="async">Whether this method should run asynchronously.</param>
/// <param name="cancellationToken">Cancels outstanding requests.</param>
/// <returns>Returns the result of the callback or the next rate limiter.</returns>
internal abstract ValueTask<TResult> Execute<State, TResult>(AsyncFlagFunc<State, ValueTask<TResult>> callback, State state, bool async, CancellationToken cancellationToken = default);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering - using a delegate here might introduce some overhead we can avoid. I'm going to try a quick benchmark test to verify what I'm thinking, let me get back to you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on @benrr101 's benchmarking, delegates are the slowest (compared to lambdas and concrete functions). I'll give this setup some thought as I implement the logic of the callback to see if this setup still makes sense or if we can switch to something more performant while still preserving the intent of the interface we expose to the rate limiters.

Copy link
Contributor

@benrr101 benrr101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds pretty good to me 👍

@mdaigle mdaigle merged commit d7f17d1 into dotnet:feat/sqlclientx Jul 15, 2024
9 checks passed
@mdaigle mdaigle deleted the throttling-scaffolding branch July 15, 2024 22:50
@mdaigle mdaigle linked an issue Jul 15, 2024 that may be closed by this pull request
@mdaigle mdaigle mentioned this pull request Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't throttle connection creation
4 participants