-
Notifications
You must be signed in to change notification settings - Fork 292
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
Pooled connection ramp up slow when using "Active Directory Default" authentication #1473
Comments
Is it AAD username password or just regular username /password? |
Regular SQL Server username/password (as the server admin user, for example). |
@ascott18 Isn't it expected? Acquiring token is a time consuming process from AAD server and it takes some time when it runs for the first time, but when first token is acquired the process is expedited as the token is cached and being reused. |
@JRahnama Token caching/reuse doesn't appear to be happening. Connections after the first connection don't seem to happen any faster than the first. See the collapsed "Output from Repro" in my first post. There doesn't seem to be any parallelization in spawning pooled connections. A single thread opening 20 connections can open them with the exact same speed as 20 threads each opening one connection. Is this intended? I'd be curious to know why, if so. Is it an intentional throttle on the connection pool to prevent the pool's connection count from spiking? If that's the case, perhaps the throttle period could be made to discount the time spent on acquiring the auth token. |
Did you ever find a resolution to this? I am experiencing the same issues connecting via Entity Framework Core and Visual Studio. |
The connection pooler opens connections serially, by design. There is caching of access tokens within a pool, but the cache is only checked before a connection request is sent to the pooler. So 20 simultaneous connections will not benefit from that cache. If you "warm up the pool" first by opening one connection before calling open on any others, subsequent connections will get the cached token and should be opened much faster. We do have an opportunity to improve MDS here, though, by caching tokens from the underlying library used by Active Directory Default. |
Addressed in #2380 |
Describe the bug
I have a web application that uses Hangfire w/ SQL server storage. On startup, Hangfire spawns many worker threads, each of which needs a database connection.
I'm using "Active Directory Default" as the authentication method against an Azure SQL Database. When running on localhost, it spends quite a while making failed requests to Azure IMDS before falling back on using other methods. In my case, the configured authentication source is Visual Studio.
When a lot of connections are opened at once (at app startup), many of them time out. Timeouts are never hit using username/password auth.
To reproduce
Run the following, once with
Active Directory Default
, and once with username/password auth.For me, username/password established 20 connections in 8 seconds. AAD did 12 connections in ~15 seconds, and then the rest timed out. Password auth was therefore about 3x faster.
Output from Repro
Expected behavior
Using Azure authentication does not cause connection ramp-up to be 3x slower.
Further technical details
Microsoft.Data.SqlClient version: (found on the nuget or Microsoft.Data.SqlClient.dll) 4.0.0
.NET target: (e.g. Framework 4.7.1, Core 2.2.2) 6.0.1
SQL Server version: (e.g. SQL Server 2017) Azure SQL Database
Operating system: (e.g. Windows 2019, Ubuntu 18.04, macOS 10.13, Docker container) Windows 10
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: