Why multi-threading and blocking I/O in IIS RRS feed

  • Question

  • Say I have a request labeled with ReqA. This is what i've understood so far

    1. ReqA comes to IIS.
    2. This request is processed by HTTP.SYS
    3. HTTP.SYS passes this request to the appropiate Application Pool
    4. Application Pool passes this request to Worker Process (w3wp.exe)

    Now the next level :

    1. Each Worker Process has two Thread Pools a. Worker thread pool b. I/O thread pool
    2. Each Thread Pool has it's own Queue a. Request Queue b. I/O Queue (each consisting of 100 threads)
    3. ReqA enters Worker thread pool.

    Similarly, request ReqB will follow the above steps and finally enters the Worker thread pool. Now, if ReqC is the 101th request, then it will wait in Request Queue of Worker thread pool. This is the reason why 100 user can enter a site hosted in IIS at the same time.

    Have i understood all correctly??

    My question is, where is myth of blocking I/O (as IIS is blocking I/O prior to node) and multi-threading?

    Saturday, January 3, 2015 4:17 PM

All replies

  • I think you are asking why IIS has considered poor at multitasking vs. something like node.js? IMO this is because of the blocking nature of the default configuration used to support ASP.NET makes use of Sessions and to enable that it will take out locks to ensure the session doesn't find itself in an unstable state. However, you can disable the session state the lock will not be taken out. The point is that out of the box ASP.NET has lots of features that are NOT aimed at high throughput. Wheras node.js starts from almost no feature support and you have to implement the features to provide the session state.

    Monday, January 5, 2015 9:38 AM
  • Hi six_sic6,

    You might also try the IIS forum for this question?

    Esther Fan | Visual Studio | If a post answers your question, please mark it as the answer. Thanks!

    Monday, January 5, 2015 8:47 PM