处理ASP请求
图1说明了一个典型的ASP请求的处理流程。该请求由WAM对象进行初始化处理。该WAM对象再把它发送给ASP-RunTime。ASP-RunTime通过创建一个内部页面对象对其进行响应。
WAM对象是一个自由线程对象。当它调用诸如ASP.DLL的ISAPI扩展时，它使用由IIS-RunTime维护的线程池所分配的MTA模型的线程。
创建ISAPI扩展时面对的一个棘手的问题是，如何处理由这一MTA线程池所带来的线程并发与同步的问题。ASP-RunTime通过在运行ASP脚本前把每个ASP请求切换至一个单线程单元(STA)，从而使问题得到简化。ASP-RunTime管理一个独立的STA辅助线程池(在后台，ASP实际上通过使用COM+线程池来实现这一点)。ASP设计师创建了这种线程池方案，以在并发和资源利用之间提供一种优化平衡，同时消除对程序员实现同步的需要。
图 1
图2说明了ASP-RunTime是怎样把每个请求从MTA线程切换到STA线程的。ASP-RunTime调度机制把每个请求都放到一个中央请求队列中。由ASP管理的线程池中的STA线程监视该队列并以先进先出方式处理请求。注意，这一线程池的大小是动态变化的。ASP-RunTime在通信高峰期会产生额外的线程，而在通信较少时释放线程。
图 2
切换到STA线程有效地解决了并发性问题，但是这样对于性能也有明显的影响。在一个单独的MTA线程中队每个请求进行处理的ISAPI扩展DLL都能提供更快的响应时间。
IIS提供了一种方法以对STA线程池和请求队列的最大尺寸进行设置。线程池的大小由IIS元数据库中AspProcessorThreadMax主键控制。该主键的缺省设置是每进程每处理器25（评论：此数字最好能找到微软的相关文档证明一下。有人说这个数目是10个/CPU）。也就是说，在一台四处理器计算机中，每个处理ASP的进程可以最多有100个辅助线程。除非对调整线程池的相关问题已经考虑成熟，否则应该避免改变该键值。注意，你不能使用Internet Server Manager来改变这个设置。必须使用管理脚本或者VB应用来进行修改。
IIS为ASP请求队列设置了一个最大容量。缺省情况下，ASP-RunTime允许队列最多容纳3000个请求（微软的另一篇文档指出，这个队列只能容纳500个请求）。一旦超出，后来进入的ASP请求就会被拒绝，返回错误信息为“Server Too Busy”。
可以使用IIS管理对象和ADSI来编程修改AspProcessorThreadMax主键和AspRequestQueueMax主键。例如，在一个Standard EXE项目中，引用Active DS类型库，编写如下代码：
Dim MyWebServer As ActiveDS.IADs
Set MyWebServer = GetOject(“IIS://Localhost/W3SVC”)
MyWebServer.Put “AspProcessorThreadMax”, 30
MyWebServer.Put “AspRequestQueueMax”, 1500
MyWebServer.SetInfo
下面简单总结一下在单处理器计算机上以缺省方式安装的IIS中，ASP线程池是怎么工作的。该线程池对于每个处理器有25个STA辅助线程可用。当一个请求到达时，就被放到请求队列中，ASP-RunTime从线程池中调度一个空闲STA线程，如果存在一个可用的话（注意，这种方案允许线程池中的任何线程都可以对请求进行处理）。如果没有空闲的辅助线程，请求就加入队列。只要队列没有达到缺省最大容量，所有请求都将得到处理。
来自Ted Pattison的《Programming Distributed Application with Visual Basic 6.0》
