I read this article and know something about IHttpAsyncHandler.
According to below picture,there are 2 threads created when I call an AsyncHandler.
When a request comes, IIS will grab a thread——Thread 1 to handle this request, and when it calls the beginXXX method, the thread 2 will be created and handle this real logic.
My questions are:
When Thread 2 is running,the connection is still stay,waiting for the response.
When Thread 2 is running, what's the status of Thread 1? Is it sleeping? Or it is released?
If the Thread 1 is sleeping, when Thread 2 is finished, Thread 1 is awoken and send the response??
If the Thread 1 is released, when Thread 2 is finished, is there a new thread created as Thread 1? And this new Thread 1 send the response to the client.
Thread 1 and Thread 2 are in the same Thread pool, aren't they ?? If so, the available threads count is balanced, what's the purpose to do like this?
You are not thinking of the Thread Pool as a pool. When "Thread 1" finishes its work at the PreRender it is returned to the pool to be reused for any purpose. When the data is ready
Endwill pick a random thread from the thread pool and finish its work and send the response on it. That random thread could be a new thread or it could be the same thread that did the work earlier that was returned to the pool.The point of this is in the window between
BeginandEndthat thread was retuned to the pool and could be servicing other connections. This allows you to have more concurrent connections than concurrent threads your system can handle, in the synchronous version once you hit the maximum number of concurrent threads you can no longer process new requests.Let me go in to some detail of what is going on
Here is a timeline for a two synchronous connection request to show as a baseline, for simplicity sake we will say every step takes 1ms to execute except
PreRenderwhich takes 19ms to complete.And here is the timeline for the async version.
Now when dealing with two or less connections there is no real benefit for asynchronous, in fact it might even be slightly slower due to the additional overhead.
However see what happens when we have more than 2 concurrent connections.
Sync:
Async:
Notice that in the sync version connection 3 came in at 20ms but it had to wait until 30ms when a thread became available to process the request. In contrast the async version gave the threads back in to the pool while it was waiting for PreRender to finish so connection 3 was immediately able to start processing.
So using async does not increase Transactions Per Second, in fact it will likely slightly lower it. However what it does do is increase your "Max Concurrent Transaction" count and increase your total throughput.