Application Insights Profiler and "AWAIT_TIME"

user_189993 0
Viewed 1452

What is actually going here? The actual call takes 8000ms, but the actual DB-call only takes <100 ms. This is the result from a load test which peaked at around 100 req/s on a Web App in Azure. I tried both to scale out and up, but the performance was still the same. The call is done async and during early days the profilers weren't very accurate for that kind of requests, but it's 2017 now...

So, can anyone tell me where or what it's waiting for? There are no other hot paths or long calls in the profiler trace, however, there are other DB- and REST-calls within the whole request and they are also done asynchronously (and done right with await and not .Result).

There are not complex method either, but mostly external async calls. Thread pool exhaustion? We are using ASPNET.CORE with netframework451

Any insight is very much appreciated.

profiler image

azure-application-insights azure asynchronous profiling c#
1 Answers

In my opinion, this is right thing. I guess you may not understand await clearly.

From azure article.

Waiting (AWAIT_TIME)

AWAIT_TIME indicates the code is waiting for another task to complete. This typically happens with C# 'await' statement. When the code does a C# 'await', the thread unwinds and returns control to the thread-pool, and there is no thread that is blocked waiting for the 'await' to finish. However, logically the thread that did the await is 'blocked' waiting for the operation to complete. The AWAIT_TIME indicates the blocked time waiting for the task to complete.

So the your code is still blocked wait for the async calls complete, but the will release the thread to do other things.

user_76090930
Related