-
Notifications
You must be signed in to change notification settings - Fork 45
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
Work out why SQL tests are 3x slower than others #22
Comments
I think it is due to startup time. SQL Server is painfully slow to actually be ready to accept connections compared to the other ones. But there might be something else as well, of course |
Filling in some info here: While SQL is slow to start, it's not drastically slower than MySql on my machine, and the startup is only once per run which doesn't explain the speed of the individual tests.
I re-pointed my sql unit tests at a local SQL instance (not docker) and it's still much slower than the other DB's so def something weird going on. I'll keep digging... |
It's the Dbase create:
|
* Turned OFF connection pooling on SQL Server connection string for tests - Found several discussions on this, e.g. dotnet/SqlClient#601 - Tried turning off pooling, and it solved the problem... * Upgraded SQL server docker image used in test from 2017-latest to latest (2019 at the time) - didn't make any difference, just to stay current.
* Turned OFF connection pooling on SQL Server connection string for tests - Found several discussions on this, e.g. dotnet/SqlClient#601 - Tried turning off pooling, and it solved the problem... * Upgraded SQL server docker image used in test from 2017-latest to latest (2019 at the time) - didn't make any difference, just to stay current.
The whole issue was apparently connection pooling. I don't know exactly, but we use a lot of different connection string (multiple databases), so we get one connection pool per connection, and (not very surprisingly), there seems to be quite a lot of overhead creating a connection pool, at least when we only use each pool a small amount of time, and then move on. |
* Turned OFF connection pooling on SQL Server connection string for tests - Found several discussions on this, e.g. dotnet/SqlClient#601 - Tried turning off pooling, and it solved the problem... * Upgraded SQL server docker image used in test from 2017-latest to latest (2019 at the time) - didn't make any difference, just to stay current.
No description provided.
The text was updated successfully, but these errors were encountered: