First database connection takes much longer on some machines when using managed SNI

[Ririshi]

I'm using SqlClient 5.2.2 with EFCore 8.0.11 in multiple .NET 8.0 apps. I'm finding that using the AppContext switch to enable managed SNI causes a very noticeable slowdown in some cases. The first time the app makes a database connection, it takes a lot longer on some machines compared to others.

We use context.Database.CanConnect() to check if we can connect to the database before continuing the startup.
When running on my local development machine (Windows 10 laptop), this check absolutely takes less than a second.
However, when running on the production machine (Windows Server 2019 Datacenter VM), it takes around 15 seconds to make the first connection.

Afterwards, the apps run completely fine without any perceived slowness. In both cases, I'm connecting to the same database server (MS SQL Server 2019), hosted on a separate VM, using its IP address in the connection string. I'm using the same login details (username + password) for both connections.

My first feeling is that it has to wait for something to time out before moving on, but I haven't found out how to debug this. I'm hoping someone can help me figure out what is going on here, unless this simply falls under "it's not production ready, don't use it yet". Please let me know if you need other information to be able to help!

[MichelZ]

Just a comment that's not really helping, but in case you did not know:
https://learn.microsoft.com/en-us/sql/connect/ado-net/appcontext-switches?view=sql-server-ver16#enabling-managed-networking-on-windows

This switch toggles the driver's behavior to use a managed networking implementation in .NET Core 2.1+ and .NET Standard 2.0+ projects on Windows, eliminating all dependencies on native libraries for the Microsoft.Data.SqlClient library. It is for testing and debugging purposes only.

[Ririshi]

Yeah, thanks, I did guess that might be the case in my OP. Regardless, I imagine the managed version should one day be production-ready, so it would be interesting to explore and fix this issue.