asp.net core - Should async controlles always used in MVC for data access

Question

ERP+Shopping cart ASP.NET MVC 4.8 application is planned to migrate to .NET 5 MVC Core application. Entity Framework Core with NpgSql data provider is planned to use.

MVC 4.8 application does no use any async method.

There are async methods in .NET 5 for Data Accesss like ToListAsync(), ExecuteSqlInterpolatedAsync().

Samples of Core MVC Controllers return async tasks like

    [HttpPost]
    public async Task<IActionResult> LogOn(LogOnModel model, string returnUrl,
        [FromServices] ShoppingCart shoppingcart
        )

There will be 100 human users. Application has also Web API providing json data over http. Shopping cart part allows anonynous access an is scanned by search engines.

Ngpsql has connation pooling support so multiple connections are added automatically. Application is hosted in Debian Linux VPS server with 4 Cores using Apache.

VSP has 20 GB of RAM so lot of data is cached by Linux. However probably most of time is still consumed by reading data from Postgres database. Most controllers read and write data to/from database.

Answer in

https://forums.asp.net/t/2136711.aspx?Should+I+always+prefer+async+actions+over+sync+actions+

recommends to use async methods for data access always.

Answer in Always using Async in an ASP.NET MVC Controller

recommends not to use async always.

Conclusion from https://gokhansengun.com/asp-net-mvc-and-web-api-comparison-of-async-or-sync-actions/ states

However async actions do not come with zero cost, writing async code requires more care, proficiency and it has its own challenges.

Application and Database in in same VPS server

Answer in

mvc should everything be async

states that async should not used if application and database are in same server.

Answer in

When should I use Async Controllers in ASP.NET MVC?

states

I'd say it's good to use it everywhere you're doing I/O.

but afterwards:

If you're talking about ASP.NET MVC with a single database backend, then you're (almost certainly) not going to get any scalability benefit from async. This is because IIS can handle far more concurrent requests than a single instance of SQL server (or other classic RDBMS)

There two upgrade paths in my case:

1. Continue to use only sync methods. Don't waste resources on async. Existing tested MVC controllers code can used. Number of threads in kestrel is not limited. Assume in future .NET compiler creates async code by analyzing application and manual async will become obsolete.

2. Change MVC controllers signatures to

   public async Task

   Replace all EF data access calls with async calls. Assume this is solid .NET feature which remains. Re-factor code so that Visual Studio 2019 warnings will not appear after change. After my application is released this allows to optimize existing code without major re-write.

Which upgrade path should used in this case ? Will changing everything to async introduce new bugs in code ?

question from:https://stackoverflow.com/questions/65932609/should-async-controlles-always-used-in-mvc-for-data-access

Answer 1

Async is not mandatory for web applications. It is mostly mandatory for GUIs only.

Your application will continue to work. Async programming is great at handling scale of requests. But you said you have at most 100 users. If they were 100.000, your application would have suffered a lot.

And I can tell for sure that async programming does come with challenges, because for example there are issues with transactions if you don't handle it properly.

Of course threads come with a cost too. Async exists to avoid the 500KB of overhead that is required for every thread. This means that the machine(s) running the application might need to be scaled vertically. In this sense, async saves RAM.

The choice is yours. Since you are refactoring your app anyways, you could work on improving it to the next step and get it ready for bigger scale.

Otherwise your application will still work fine for 100 users.

[Edit] a pull request is worth 1000 words. In async context, the transaction should be initialized with TransactionScopeAsyncFlowOption.Enabled to avoid the exception descripted and in order to tell the transaction engine that the thread is participating an async flow. To keep it simply simple, async flows share the same thread, so application code (and transaction management is C# code) must not rely on thread-local information and has to clean up context every time the context is switched to another async flow asking for attention.

Conclusion: your first comment is correct. Async flows dramatically reduce RAM utilizations on concurrent requests.