ASP.NET Core, how it handle concurrent request when async involved?

Question

Any idea how ASP.net core handle concurrent request when a async involved. As you can see from the log below, the request finished time seem like in sequence rather than in parallel or concurrently? I might understand the async wrong, hope someone can explain why below request finished timing is in sequence rather identical timing? I was expecting at least each of the request should finish in almost identical time?

Connection id "0HL9BC18TNP25" started.
Connection id "0HL9BC18TNP26" started.
Connection id "0HL9BC18TNP27" started.
Connection id "0HL9BC18TNP28" started.
Connection id "0HL9BC18TNP29" started.
Connection id "0HL9BC18TNP2A" started.
Connection id "0HL9BC18TNP2B" started.
Connection id "0HL9BC18TNP2C" started.
Connection id "0HL9BC18TNP2D" started.
Connection id "0HL9BC18TNP2E" started.
Connection id "0HL9BC18TNP2C" completed keep alive response.
Request finished in 45.2835ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP2C" received FIN.
Connection id "0HL9BC18TNP2C" disconnecting.
Connection id "0HL9BC18TNP2C" sending FIN.
Connection id "0HL9BC18TNP2C" sent FIN with status "0".
Connection id "0HL9BC18TNP2C" stopped.
Connection id "0HL9BC18TNP2D" completed keep alive response.
Request finished in 175.3974ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP2D" received FIN.
Connection id "0HL9BC18TNP2D" disconnecting.
Connection id "0HL9BC18TNP2D" sending FIN.
Connection id "0HL9BC18TNP2D" sent FIN with status "0".
Connection id "0HL9BC18TNP2D" stopped.
Connection id "0HL9BC18TNP27" received FIN.
Connection id "0HL9BC18TNP27" completed keep alive response.
Request finished in 171.6836ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP27" disconnecting.
Connection id "0HL9BC18TNP27" sending FIN.
Connection id "0HL9BC18TNP27" sent FIN with status "0".
Connection id "0HL9BC18TNP27" stopped.
Connection id "0HL9BC18TNP26" completed keep alive response.
Connection id "0HL9BC18TNP26" received FIN.
Request finished in 179.5263ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP26" disconnecting.
Connection id "0HL9BC18TNP29" completed keep alive response.
Request finished in 189.1427ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP2B" completed keep alive response.
Request finished in 179.8384ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP26" sending FIN.
Connection id "0HL9BC18TNP2E" completed keep alive response.
Connection id "0HL9BC18TNP2E" received FIN.
Request finished in 187.7259ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP2B" received FIN.
Connection id "0HL9BC18TNP29" received FIN.
Connection id "0HL9BC18TNP2B" disconnecting.
Connection id "0HL9BC18TNP2E" disconnecting.
Connection id "0HL9BC18TNP29" disconnecting.
Connection id "0HL9BC18TNP26" sent FIN with status "0".
Connection id "0HL9BC18TNP26" stopped.
Connection id "0HL9BC18TNP2B" sending FIN.
Connection id "0HL9BC18TNP2E" sending FIN.
Connection id "0HL9BC18TNP29" sending FIN.
Connection id "0HL9BC18TNP2E" sent FIN with status "0".
Connection id "0HL9BC18TNP2E" stopped.
Connection id "0HL9BC18TNP2B" sent FIN with status "0".
Connection id "0HL9BC18TNP2B" stopped.
Connection id "0HL9BC18TNP29" sent FIN with status "0".
Connection id "0HL9BC18TNP29" stopped.
Connection id "0HL9BC18TNP28" completed keep alive response.
Request finished in 190.027ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP28" received FIN.
Connection id "0HL9BC18TNP28" disconnecting.
Connection id "0HL9BC18TNP28" sending FIN.
Connection id "0HL9BC18TNP28" sent FIN with status "0".
Connection id "0HL9BC18TNP28" stopped.
Connection id "0HL9BC18TNP2A" received FIN.
Connection id "0HL9BC18TNP2A" completed keep alive response.
Request finished in 209.3495ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP2A" disconnecting.
Connection id "0HL9BC18TNP2A" sending FIN.
Connection id "0HL9BC18TNP2A" sent FIN with status "0".
Connection id "0HL9BC18TNP2A" stopped.
Connection id "0HL9BC18TNP25" completed keep alive response.
Request finished in 223.5798ms 200 application/json; charset=utf-8
Connection id "0HL9BC18TNP25" received FIN.
Connection id "0HL9BC18TNP25" disconnecting.
Connection id "0HL9BC18TNP25" sending FIN.
Connection id "0HL9BC18TNP25" sent FIN with status "0".
Connection id "0HL9BC18TNP25" stopped.

Please take a look at this answer https://stackoverflow.com/questions/44391268/how-to-configure-concurrency-in-net-core-web-api — bonzaster, Jan 05 '18 at 10:03

score 1 · Answer 1 · answered Nov 14 '17 at 14:26

1

Async != parallel. Async does one thing and one thing only, it allows the thread to be returned to the pool when it is idle, so if can do other work instead of sitting idle. Period. That is all. When you await an asynchronous task, you code does not magically move on and keep processing. It "waits" (hence await) for the work to be completed.

If you do want to run a bunch of asynchronous tasks at the same time, you can use Task.WhenAll:

var tasks = new Task[]
{
    DoFirstAsync(),
    DoSecondAsync(),
    DoThirdAsync()
};
await Task.WhenAll(tasks);

This essentially just creates a Task that waits on all the other Tasks to complete, so you can await this instead.

answered Nov 14 '17 at 14:26

Chris Pratt

232,153
36
385
444

But how ASP.NET CORE web api handle concurrent request? I was expecting that if two request hitting the code there should have two separate thread executing at the same time? I might understand it wrong. From the explanation, sound like other requests have to wait for the previous to complete before they can proceed? – Maven Cheong Nov 14 '17 at 14:52
Oh. You're talking about handling requests concurrently. That really has nothing to do with async one way or another. A web server typically has a thread pool of around 1000 threads and can therefore handle up to 1000 simultaneous requests. However, importantly, IIS Express, which is likely where you're doing your testing here, is *single-threaded*. Which means it handles only one request at a time, always. It's meant for development, so it doesn't need to be multithreaded. – Chris Pratt Nov 14 '17 at 14:57
That's the problem, i dont see that they are being executed in different threads? By right the request completion time should be nearly identify and shouldn't be accumulated. Look that they are waiting for the next to complete before their turn. – Maven Cheong Nov 14 '17 at 16:13
Again, where are you running this. If it's in development, they will always be handled serially, because you only have one thread to work with. If it's full IIS, they should run parallel, unless you're thread-starved. – Chris Pratt Nov 14 '17 at 17:09
I'm running the web api within docker container (nginx as recerse proxy + kestrel) and the host is using AWS m4.large instance. – Maven Cheong Nov 15 '17 at 00:54

ASP.NET Core, how it handle concurrent request when async involved?

1 Answers1