IIS 5.0 and 6.0 的线程分派
位于IIS5.0上的请求是典型的基于I/O线程的响应，或者是线程异步实现I/O，因为使用异步写命名管道把这些请求分派给工作进程。当工作进程中响应一个请求时，它将会使用异步读取的线程。位于工作进程中用来响应请求的线程来自于进程范围的CLR线程池。尽管线程池的线程通过绑定I/O实施端口不正确是返回错误（IsThreadPoolThread of Thread），但是不要指望使用这个属性。
尽管在IIS5.0响应请求的服务是基于I/O线程，但在重的负载下，一些请求将被终止为了正常的来自于池的工作线程，因此两种线程会被同时激发。默认CLR线程池大小是25，分离了I/O线程和工作线程。有可以更改线程池的上限，如前所述。
情况发生了巨大的变化在IIS6上（2003）。首先，inetifo.exe不再用于响应Http的请求。作为取代的是，http请求置于内部方式队列中，http.sys 用来分发每一个合适的应用队列。另外，IIS6支持应用池，能够共享单个的工作进程，现在的命名为w3pwp.exe。应用池在许多的不同的工作进程中给你选择，依赖你对分离你的web应用的程度。
这个范例改变asp.net响应请求的处理方式。使用分发请求从inetinfo.exe到asp.net工作进程，http.sys直接在合适的进程中对每一个请求予以排队。所有的请求现在有来自CLR线程池的工作进程来响应，再也不用I/O线程。于2003上的machine.config发现的描述，进程模式仍然初始化线程池的上限，然而另外所有的属性都被忽略，它们现在存储于IIS6的元数据上。
对异步的要求
许多因素影响着web应用的扩展性。通常，任何情况下，多个并发的操作请求去访问共享资源，系统的扩展性就会受到损害，以上系统共享资源列表是CPU本身（ 或位于多个处理箱的CPU集）。运行asp.net的服务器有其自己CPU，其共享依赖于线程池的方式的并发请求。这种线程池目的为了有效的分派CPU处理请求的时间，线程池的总数分派是有其上限的。这是一个重要的约束对于有的地方，正如当有大量并发请求时，创建没有界定线程数量能够很容易让系统停止。
然而，如果位于线程池的线程被用来执行非CPU-intensive工作（比如对远程数据一个请求或调用一个远程的web服务），这就会影响线程池，不会有较高的CPU利用率。这中情形下，事实上线程池降低了系统的扩展性，这是因为请求会被延迟（或可能被拒绝）即使服务器并非在忙于处理其它请求。
例如一个沼泽线程池的例子，接下来的asp.net页面，slow.aspx, 其人工的延迟服务响应时间两秒并且打印出线程,正如:
<!-- File: slow.aspx -->
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Reflection" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
protected void Page_Load(object src, EventArgs e)
{
System.Threading.Thread.Sleep(2000);
Response.Output.Write("SlowResponse, threadid={0}",
AppDomain.GetCurrentThreadId());
}
</script>
另一个asp.net 页面,fast.aspx, 相比slow.aspx来说,除了不休息两秒是一样的:
<%@ Page Language="C#" %>
<%@ Import Namespace="System.Reflection" %>
<script runat="server">
protected void Page_Load(object src, EventArgs e)
{
Response.Output.Write("FastResponse, threadid={0}",
AppDomain.GetCurrentThreadId());
}
</script>
使用web应用压力工具来检测这两个页面,你可以发现在大量请求的情况下测试的平均响应时间. 最初的对于fast.aspx页面的平均响应时间为0.0824秒, 在1分钟的时间内响应52,190个请求.同时测试fast.aspx和slow.aspx, fast.aspx时间为4.47秒,slow.aspx为6.54秒, 请求次数的总数量在1分钟减少到1062次.
