May 162006
 

今天下载了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程序提供商,你们的产品存在类似问题。尽快改进你们的产品吧。现在还可以以兼容性作为理由,但不要等所有问题日后暴露出来再想办法。

  2 Responses to “所谓万事皆有其因,关于IIS6中ASP随机hang终于有眉目了”

  1. 刚才又仔细看了下IISDiag,不由得再佩服微软一下,所谓这个工具,也只是活用了Debugging Tools,url monitor,log parser等东西堆砌起来的,但研究下IISAnalysis.asp的代码就会感受到这么简单的几个工具利用好所能起到的巨大功用。想想当年在dos目录挖宝的情形吧,现在Windows目录到底还隐藏了多少有用的东西你知道吗?

  2. 我的不是ASP,是aspx,IIS目前是一天好几次,无响应,不知道是Crash还是hang了。正在用此软件监控中,好像还没有监控到任何信息。

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>