在你的服务器端代码中使用线程和创建异步处理(3)

在你的服务器端代码中使用线程和创建异步处理(3)

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处理请求的时间，线程池的总数分派是有其上限的。这是一个重要的约束对于有的地方，正如当有大量并发请求时，创建没有界定线程数量能够很容易让系统停止。