locked
Should async controlles used in migration to EF Core RRS feed

  • Question

  • User-1262787652 posted

    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 ) </iactionresult>

    <iactionresult>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. </iactionresult>

    <iactionresult>Application is hosted in Debian Linux VPS server with 4 Cores using Apache. </iactionresult>

    <iactionresult>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. </iactionresult>

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

    <iactionresult> recommends to use async methods for data access always. </iactionresult>

    <iactionresult>Answer in https://stackoverflow.com/questions/27460579/always-using-async-in-an-asp-net-mvc-controller </iactionresult>

    <iactionresult>recommends not to use async always. </iactionresult>

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

    <iactionresult>However async actions do not come with zero cost, writing async code </iactionresult>

    <iactionresult>requires more care, proficiency and it has its own challenges.</iactionresult>

    <iactionresult> Application and Database in in same VPS server </iactionresult>

    <iactionresult>Answer in https://stackoverflow.com/questions/26552327/mvc-should-everything-be-async states that async should not used if application and database are in same server. </iactionresult>

    <iactionresult>Answer in https://stackoverflow.com/questions/30566848/when-should-i-use-async-controllers-in-asp-net-mvc states</iactionresult>

    <iactionresult> > I'd say it's good to use it everywhere you're doing I/O. but afterwards: </iactionresult>

    <iactionresult>> If you're talking about ASP.NET MVC with a single database backend, </iactionresult>

    <iactionresult>> then you're (almost certainly) not going to get any scalability </iactionresult>

    <iactionresult>> benefit from async. This is because IIS can handle far more concurrent </iactionresult>

    <iactionresult>> requests than a single instance of SQL server (or other classic RDBMS) </iactionresult>

    <iactionresult>There two upgrade paths in my case: </iactionresult>

    1. <iactionresult>Continue to use only sync methods. Don't waste resources on async. Existing tested MVC controllers code can used. </iactionresult>
    2. <iactionresult>Change MVC controllers signatures to public async Task<iactionresult> Replace all EF data access calls with async calls. Re-factor code so that Visual Studio 2019 warnings will not appear after change. </iactionresult></iactionresult>

    <iactionresult><iactionresult>Which upgrade path should used ? </iactionresult></iactionresult>

    <iactionresult><iactionresult>Continuing using only sync methods makes upgrading easier. Will changing everything to async introduce new bugs in code ? </iactionresult></iactionresult>

    Thursday, January 28, 2021 8:28 AM

All replies

  • User-1545767719 posted

    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.
    2. Change MVC controllers signatures to public async Task Replace all EF data access calls with async calls. Re-factor code so that Visual Studio 2019 warnings will not appear after change.

    Which upgrade path should used ?

    Of course, choice must be 2 as far as you can. Read the following Microsoft document:

    ASP.NET Core Performance Best Practices

    Thursday, January 28, 2021 8:44 AM
  • User475983607 posted

    The recommendation since the beginning of programming has always been to use asynchronous when available.   This goes back to the 8085 and Z80 which are microprocessors from the 1970s.

    Let's say you want to print a document.  You don't want the computer to stop while the printer prints, right? The printer is smart enough to print without the help of the CPU.  The CPU can do other task while the printer is printing. The printer simply reports back to the CPU when the print job is complete.  That's asynchronous.  

    I recommend learning the fundamental concepts.  Then you can make better design decisions.  

    https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/

    Thursday, January 28, 2021 12:31 PM
  • User-474980206 posted

    If you are talking asp.net 4.* then sync database calls are better supported. This is because thread pools are used for processing request, response and actions. If you need high scaling then async will help with thread starvation. 

    but using thread pools limits absolute performance due to the thread management and context switches. Asp.net core was designed to use an async pipeline (multiple requests on the the same thread at the same time). The original version of asp.net core only had one pipeline thread and all requests were processed on this thread. Any sync operation blocked all requests. But as long as async operations were used, asp.net core was an order of magnitude faster than classic asp.net.

    in later versions of asp.net core, additional processing threads were added (typically one per cpu). This allow more requests and limits the performance cost of sync operations, but if it’s a busy site, sync operations will block other requests.

    if your code will never migrate to asp.net core, or you can scale out your server (add CPU’s or servers) to match load than the upgrading the code to async may not be necessary.

    note: async operations have always been important shared services like a web server, but in desktop pro games, using sync helped with sharing the resources.

    Thursday, January 28, 2021 3:42 PM