IDC资讯中心
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次.
