June 30, 2021
Here is the link.
This article provides guidelines for performance best practices with ASP.NET Core.
Cache aggressively
Caching is discussed in several parts of this document. For more information, see Response caching in ASP.NET Core.
Understand hot code paths
In this document, a hot code path is defined as a code path that is frequently called and where much of the execution time occurs. Hot code paths typically limit app scale-out and performance and are discussed in several parts of this document.
Avoid blocking calls
ASP.NET Core apps should be designed to process many requests simultaneously. Asynchronous APIs allow a small pool of threads to handle thousands of concurrent requests by not waiting on blocking calls. Rather than waiting on a long-running synchronous task to complete, the thread can work on another request.
A common performance problem in ASP.NET Core apps is blocking calls that could be asynchronous. Many synchronous blocking calls lead to Thread Pool starvation and degraded response times.
Do not:
- Block asynchronous execution by calling Task.Wait or Task.Result.
- Acquire locks in common code paths. ASP.NET Core apps are most performant when architected to run code in parallel.
- Call Task.Run and immediately await it. ASP.NET Core already runs app code on normal Thread Pool threads, so calling Task.Run only results in extra unnecessary Thread Pool scheduling. Even if the scheduled code would block a thread, Task.Run does not prevent that.
Do:
- Make hot code paths asynchronous.
- Call data access, I/O, and long-running operations APIs asynchronously if an asynchronous API is available. Do not use Task.Run to make a synchronous API asynchronous.
- Make controller/Razor Page actions asynchronous. The entire call stack is asynchronous in order to benefit from async/await patterns.
A profiler, such as PerfView, can be used to find threads frequently added to the Thread Pool. The Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start event indicates a thread added to the thread pool.
Return large collections across multiple smaller pages
A webpage shouldn't load large amounts of data all at once. When returning a collection of objects, consider whether it could lead to performance issues. Determine if the design could produce the following poor outcomes:
- OutOfMemoryException or high memory consumption
- Thread pool starvation (see the following remarks on IAsyncEnumerable<T>)
- Slow response times
- Frequent garbage collection
Do add pagination to mitigate the preceding scenarios. Using page size and page index parameters, developers should favor the design of returning a partial result. When an exhaustive result is required, pagination should be used to asynchronously populate batches of results to avoid locking server resources.
For more information on paging and limiting the number of returned records, see:
No comments:
Post a Comment