I like how they admit right out that they pass off requests to a ThreadPool and that it's non-optimal for application performance.
Similar to IIS 6.0 (classic mode, a.k.a. ISAPI mode), the request is still handed over to ASP.NET on an IIS I/O thread. And ASP.NET immediately posts the request to the CLR Threadpool and returns pending. We found this thread switch was still necessary to maintain optimal performance for static file requests.
Author goes on to say it was done because static file serving is blocking, which ate away too heavily at a unified threadpool between IIS and ASP.NET.
I'd call out SEDA here again. Passing work items around between executors is in-advisable. That said, the typical problem to "you need a responsive request handler" is "offload the work item asap and yield," and done well there's many many right ways for that effort to look like SEDA.
It's a pretty good trade-off with a heterogeneous application workload.
There is a "to the metal" mode in ASP.NET/IIS now, mentioned in that article, that lets you use the IOCP thread directly in your applications and avoid that context switch. But, of course, if you do blocking things there it will completely block your web server.
Comments
I like how they admit right out that they pass off requests to a ThreadPool and that it's non-optimal for application performance.
Similar to IIS 6.0 (classic mode, a.k.a. ISAPI mode), the request is still handed over to ASP.NET on an IIS I/O thread. And ASP.NET immediately posts the request to the CLR Threadpool and returns pending. We found this thread switch was still necessary to maintain optimal performance for static file requests.
Author goes on to say it was done because static file serving is blocking, which ate away too heavily at a unified threadpool between IIS and ASP.NET.
I'd call out SEDA here again. Passing work items around between executors is in-advisable. That said, the typical problem to "you need a responsive request handler" is "offload the work item asap and yield," and done well there's many many right ways for that effort to look like SEDA.
It's a pretty good trade-off with a heterogeneous application workload.
There is a "to the metal" mode in ASP.NET/IIS now, mentioned in that article, that lets you use the IOCP thread directly in your applications and avoid that context switch. But, of course, if you do blocking things there it will completely block your web server.