“This article is the third day of the month watch article. For me, this is a challenge, so disorderly into a thread optimization article, come on, Webmote”

  • 📢 welcome to like: 👍 collect ⭐ message 📝 If there is any mistake please correct it, send roses, hand left fragrance!
  • 📢 This article is written by Webmote.
  • 📢 author’s motto: life lies in tossing about, when you do not toss about life, life will start tossing you, let us work together! 💪 💪 💪

Preface 🎏

It has to be said that asynchrony and thread performance issues have always been the enemy of high concurrency.

.NET Core has been improving performance since its inception, and.net 6 is currently being developed with a performance RoadMap. When I recently read EF Core’s RoadMap, I was delighted to find that the library, maintained by a small team, is starting to make changes for performance improvements.

The EF Core team in particular has a surprising statement: they will be optimizing the performance of the DapperLib library for release with.NET 6.

🎏 01.ef Core does not support running multiple parallel operations on the same context instance

EF Core does not support running multiple parallel operations on the same context instance. You should always wait for the operation to complete before starting the next operation. This is usually done by using the await keyword on each asynchronous operation.

So don’t be smart not to use await and let the operation execute on its own in the hope that asynchrony doesn’t affect the main thread.

🎏 02. Asynchronous LINQ operator for server and client

In order to support asynchronous execution LINQ query, Microsoft EntityFrameworkCore namespace is defined in EF Core asynchronous extension methods. EF Core provides a set of asynchronous extension methods that execute queries and return results. These synchronous LINQ operators that correspond to the standard include ToListAsync, SingleAsync, AsAsyncEnumerable, and so on:

var blogs = await context.Blogs.Where(b => b.Rating > 3).ToListAsync();
Copy the code

The server-side asynchronous LINQ operator can only be used with EF queries. It cannot be used with client-side LINQ to Objects queries. To perform client-side asynchronous LINQ operations outside of EF, use the system.Exception package; This package is particularly useful for performing operations on the client that cannot be evaluated on the server.

Unfortunately, there is an ambiguous call compilation error referencing system.exception and the server-side LINQ operator; This makes it difficult to use both EF and System.Object in the same project. To resolve this issue, add AsQueryable to the DbSet:

var groupedHighlyRatedBlogs = await context.Blogs
    .AsQueryable()
    .Where(b => b.Rating > 3) // server-evaluated
    .AsAsyncEnumerable()
    .GroupBy(b => b.Rating) // client-evaluated
    .ToListAsync();
Copy the code

🎏 03. The parallel asynchronous database connection method is slow or blocked

If the minimum concurrent pool number is not set, asynchronous connections are slowed down and synchronous connections are hardly affected. Therefore, the default is to add the minimum pool number parameter when building SQL connection strings.

  • Add a connection string with MinPoolSize of 100. If you add a number greater than 100, you need to change MaxPoolSize because it defaults to 100 and cannot be smaller than MinPoolSize.

  • For pooled connections, add Pooling=true to your connection string and Pooling=false for non-pooled connections

🎏 04. Asynchronous reading of big data (binary, text, images) is very slow

It takes about 5 seconds to read a VARBINARY(MAX) value of 10MB asynchronously, and about 20 milliseconds to read the same value synchronously. Increasing the data size to 20MB increases the run time to about 52 seconds.

Yes, this problem is currently unresolved. It involves Zero Copy and other thread coordination issues. Therefore, it is unlikely to be solved before Ef Core 6, so the best solution is to use synchronization for now.

🎏 05. How big is the connection pool?

Strictly speaking, this is not an EF issue, database connection pooling is a client issue, but it is something that has puzzled me for a long time, and here is the answer.

Reference value: Number of connections = ((Number of cores x 2) + Number of valid disks)

This formula is not only applicable to the database connection pool calculation, most of the calculation and I/O program, the number of threads can be set according to this formula.

So Microsoft’s default pool number is 10-100. However, due to poor thread management, our application will generally set around 100-1000, haha, this is the control gap.

It is common to see small-scale Web applications dealing with a dozen or so concurrent users using a pool of 100 connections. This will place an extremely unnecessary burden on your database.

🎏 06. Summary

I have something to do tonight, so I can only sum it up at work.

To develop a good habit requires constant encouragement and encouragement. Writing ability may be improved through continuous writing, and of course, my own capacity. In the process of continuous output, I find my own deficiencies and consolidate my knowledge.

Today is the third day. Come on!

Routine summary, rational view!

Knot is what, knot is I want you to like but can not get the loneliness. 😳 😳 😳

👓 all see this, still care to point a like?

👓 all points like, still care about a collection?

Do you care about a comment when you have collected 👓?