处理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类型库,编写如下代码: