C# 中的嵌套等待对性能的影响

Question

I am exposing a method in Api that is expecting a 500 hits from per second.

I have made all the API's as async to be responsive. there could be multiple database calls in each request, should those be async or sync.

My point is nested awaits let's say 3 levels. In such scenario, will it improve performance or the context switching badly affect the performance. I have searched enough but i am getting more confuse. There should be some rule of thumbs that i want to follow.

Also on the bottom, the database call is sync call that i couldn't do much of as already written.

Answer 1

The number of await s isn't usually important. There are some things you can do (eg, using ValueTask<T> instead of Task<T> ) if you find the performance unsuitable.

However, the big performance problem is here:

on the bottom, the database call is sync call

If the low-level call is synchronous, then you'll likely have scalability problems. If the current code is doing "async over sync" (eg, Task.Run or Task.Factory.StartNew ), then that would be a problem. Either change the code to be "async all the way" (ie, make the db call asynchronous) and accept the additional work that needs to be done, or change it to be synchronous all the way and accept the limited scalability of a synchronous solution.

Answer 2

The purpose of the asynchronous programming (ie the use of coroutines) is not to introduce performance gain, but to improve the the computing resources when you are not using them. Every await you use, introduce a "check point", where the execution might be "suspended".

While your logical code is "suspended", the underlying thread is not sleeping like it happens in the synchronous execution model. This is vital for (web)service-based APIs where you can have multiple concurrent requests: when a request is waiting for IO (both network or local), the underlying thread can still progress another request, thus improving the overall throughput of the whole service. Each request does not gain any benefit; truly, it gains a little overhead as the compiler rewrites your code into a state machine to handle the "suspension" and "resume".

For this reason, besides from benchmarking, you should choose the granularity of your analysis.