Solo Estoy

今天下载了IISDiag大体玩了一下，发现这东西真不错，诊断IIS故障有多了一个利器。
刚好有客户反映他的ASP站点老是出问题，刚好把新武器演练一下，结果居然揪出了导致IIS6种ASP请求挂起的首恶(第一恶是也，非首要恶)—-Scripting.Dictionary组件。
debug纪录显示有5个页面请求被block，原因是这些页面都请求了Scripting.Dictionary这个组件，同时这个组件被另外一个页面调用并执行，所以一旦这个页面的请求出现问题，会导致所有后续页面被block，根本原因为Scripting.Dictionary这个组件为STA模式设计，所以页面在处理Scripting.Dictionary请求时会将请求串行话，而第一个请求处理如果出现意外情况，则后续请求皆会被block。
继续检查更详细的信息，发现调用此组件是在Session处理中，具体代码为：
Set Session(strName) = Server.CreateObject(”Scripting.Dictionary”)
然后又在网上发现了这样一句话：
如果在session级保存一个dictionary对象会降低系统的性能，而在application级保存一个dictionary对象会导致web服务器崩溃
—–wrox: asp程序员参考手册里第137页
至此原因找到，一方面为客户程序没有考虑MTA环境下ASP编程的注意事项（其实很多从ASP2.0 under IIS5 过来的程序都没考虑过此问题，只是恰好出问题的几率比较小而已），另一方面是客户程序在不恰当的位置调用了不恰当的组件，导致很容易使程序被block。
相信以后会慢慢找出更多存在类似遗留问题的组件，那时对于IIS6 ASP hang故障将会有更快更准确地定位能力。
三点结论：
1，要佩服MS在新技术应用上的能力与决心，COM的STA->MTA的转换能在短时间内完成，并将绝大多数底层架构升级为MTA环境，同时考虑了兼容问题，这是需要佩服的。反观某些开源软件，底层数据结构说改就改，几天一编，同版本号的内核竟然都敢做成不兼容，虽然号称Free，但谁敢用这些产品作服务？你以为每家都有IBM的实力？
2，即使存在问题，不是掩盖而是积极解决，请看关于此问题的KB，同时又提供了如此快捷方便的工具来定位问题，试问谁能做的更好？
3，敬告国内某ASP程序提供商，你们的产品存在类似问题。尽快改进你们的产品吧。现在还可以以兼容性作为理由，但不要等所有问题日后暴露出来再想办法。