How to use Pomelo.EntityFrameworkCore.MySql provider for ef core 3 in async mode properly?

We are building an asp.net core 3 application which uses ef core 3.0 with Pomelo.EntityFrameworkCore.MySql provider 3.0.

Right now we are trying to replace all database calls from sync to async, like:

//from
dbContext.SaveChanges();
//to
await dbContext.SaveChangesAsync();

Unfortunetly when we do it we expereince two issues:

1. Number of connections to the server grows significatntly compared to the same tests for sync calls
2. Average processing speed of our application drops significantly

What is the recommended way to use ef core with mysql asynchronously? Any working example or evidence of using ef-core 3 with MySql asynchonously would be appreciated.

It's hard to say what the issue here is without seeing more code. Can you provide us with a small sample app that reproduces the issue?

Any DbContext instance uses exactly one database connection for normal operations, independent of whether you call sync or async methods.

Number of connections to the server grows significatntly compared to the same tests for sync calls

What kind of tests are we talking about? Are they automated? If so, how many tests are being run? Because of the nature of async calls, if you run 1000 tests in parallel, every test with its own DbContext, you will end up with 1000 parallel connections.

Though with Pomelo, you will not end up additionally with 1000 threads, as you would with using Oracle's provider.

Update:

We test asp.net core call (mvc) which goes to db and read and writes something. 50 threads, using DbContextPool with limit 500. If i use dbContext.SaveChanges(), Add(), all context methods sync, I am land up with around 50 connections to MySql, using dbContext.SaveChangesAsnyc() also AddAsnyc, ReadAsync etc, I end up seeing max 250 connection to MySql and the average response time of the page drops by factor of 2 to 3.

(I am talking about ASP.NET and requests below. The same is true for parallel run test cases.)

If you use Async methods all the way, nothing will block, so your 50 threads are free to handle the next 50 requests while the database is still executing the queries for the first 50 requests.

This will happen again and again because ASP.NET might process your requests faster than your database can return its results. So you will end up with a lot of parallel database queries.

This does not happen when executing the Sync methods, because every thread blocks and you end up with a maximum of 50 parallel queries (one per thread).

So this is expected behavior and just a consequence of async method calls.

You can always modify your code or web server configuration to limit the amount of concurrent ASP.NET requests.

50 threads, using DbContextPool with limit 500.

Also be aware that DbContextPool does not limit how many DbContext objects can concurrently exist, but only how many will be kept in the pool. So if you set DbContextPool to 500, you can create more than 500 contexts, but only 500 will be kept alive after using them.

Update:

There is a very interesting low level talk about lock-free database pool programming from @roji that addresses this behavior and takes your position, that there should be an upper limit in the connection pool that should result in blocking when exceeded and makes a great case for this behavior.

According to @bgrainger from MySqlConnector, that is how it is already implemented (the docs did not explicitly state this, but they do now). The MaxPoolSize connection string option has a default value of 100, so if you use connection pooling and if you don't overwrite this value and if you don't use multiple connection pools, you should not have more than 100 connections active at a given time.

From GitHub:

This is a documentation error, if you are interpreting the docs to mean that you can create an unlimited number of connections.

When pooling is true, each connection pool (there is one per unique connection string) only allows MaximumPoolSize connections to be open simultaneously. Each additional call to MySqlConnection.Open will block until a connection is returned to the pool.

When pooling is false, there is no limit to the number of connections that can be opened simultaneously; it's up to the user to manage the concurrency.