Best way to wait for SqlClient calls in ASP.Net Core 3.1

Question

I created an SPA application with Angular frontend and ASP.Net Core 3.1 backend. I use a typical RESTful API for communicating between the two, along with a SignalR based WebSocket API for some real-time push status updates. Because this application is a rewrite of an older Windows .NET program, I have a substantial codebase that uses SqlClient to interact with a common database. I want to reuse this code and not try to convert the system to EF. I have all of this working but I became worried about how calls to function s like ExecuteScalar, ExecuteReader and ExecuteNonQuery might negatively impact the performance of an ASP.Net backend running in IIS. I also need to consider GetDataAdapter and adapter.Fill but that is a different issue.

It seems I should be using Async calls to help thread management but if all I do is immediately Await the call is there any difference to using the synchronous calls? Do the synchronous calls wait nicely in IIS?

To be clear, I haven't seen any problems using synchronous or asynchronous calls. My early testing isn't under load. I would like my app to scale up to about a hundred concurrent users, maybe with a cloud host. This is why I want to get the basic architectural decision right.

If it matters, my backend runs without change in .NET 5 but I haven't committed to the upgrade yet. If .NET 5 can benefit my performance I will consider the upgrade.

Answer 1

but if all I do is immediately Await the call is there any difference to using the synchronous calls?

Yes, there's a very significant difference: it releases the thread so that instead of being blocked on network IO (and whatever your database server is doing), that thread can go and do other interesting things. Await is all about scalability of CPU resources (and in particular: threads), but there are some minor overheads involved which can make individual requests slightly slower, but not by any amount you'd ever measure.

But for context: Stack Overflow (which has much higher load than that) scales fine on IIS (it also runs in Kestrel of desired) using mostly synchronous database access (the conversion to asynchronous data access is still in progress). If your app doesn't scale to 100 users, blaming sync vs async would be passing the buck: the real problem is probably bad query performance due to suboptimal design. Async won't be the thing that makes or breaks that - it'll just help a well designed system scale even further.