监视Windows 2003/IIS 6.0中的ASP/COM +应用程序性能 [英] Monitoring ASP/COM+ application performance in Windows 2003/IIS 6.0

问题描述

我们正在使用 Active Server Pages& COM +组件. ASP页面调用COM +组件，而COM +组件又与外部系统通信并响应ASP页面请求.

We are running a website using Active Server Pages & COM+ components. The ASP pages call COM+ components which in turn communicates with external systems and respond to ASP page requests.

我们发现该应用程序在一段时间内变慢并且需要重新启动(例如几天).该网站运行良好的硬件，并且流量不高，因此我们认为这不是容量问题.

We find that the application becomes slow over a period of time and requires restarts (like in couple of days). The website runs on good hardware and does not have huge traffic and so we believe it's not a capacity issue.

该应用程序由不再支持我们的外部供应商以ASP 3.0，VB 6.0(COM)编写.在这种情况下，我们想通过监视ASP网站和COM +组件的性能来找出问题所在.

The application was written in ASP 3.0, VB 6.0 (COM) by an external vendor who does not support us any more. This being the situation, we want to figure out where the problem is by monitoring the ASP website and COM+ components' performance.

提出我的问题:

• 所有性能计数器是 最好监视这种情况?
• 计数器应间隔多长时间 被记录?
• 计数器被监视多长时间 在开始分析它们之前?一世 意识到这可能因 不同的应用程序，但在那里 一般准则?
• 一旦收集了计数器，如何 从中可以理解吗?手动的 使用MS Excel进行分析还是 有什么好的工具推荐吗?什么是 您对此的经验?

• Which all performance counters are the best to monitor for this case?
• At what interval should the counters be logged?
• How long are the counters monitored before you start analysing them? I realise this could vary for different applications but is there a general guideline?
• Once the counters are collected, how can one make sense out of it? Manual analysis using MS Excel or is there any good tool recommended? What's your experience on this?

任何帮助都受到赞赏.

推荐答案

请参见您应该从PAL Perfmon_Template_for_System_Overview.htm设置文件开始，并添加以下Active Server Pages计数器:

You should start with the PAL Perfmon_Template_for_System_Overview.htm settings file and add the following Active Server Pages counters:

• 脚本运行时错误
• 来自ASP预处理器的错误
• 执行请求
• 请求已排队
• 总会话次数
• 来自脚本编译器的错误
• 调试请求
• 请求执行时间
• 请求等待时间
• 请求数/秒
• 请求总数
• 请求成功
• 请求总数失败
• 模板缓存命中率
• 处理(inetinfo)专用字节

• Errors During Script Runtime
• Errors From ASP Preprocessor
• Requests Executing
• Requests Queued
• Sessions Total
• Errors From Script Compilers
• Debugging Requests
• Request Execution Time
• Request Wait Time
• Requests/Sec
• Requests Total
• Requests succeeded
• Requests Failed Total
• Template Cache Hit Rate
• Process (inetinfo) Private Bytes

如果您监视的时间足够长，则模板的默认采样间隔15秒应该足够好.如果您白天有几个小时的高峰使用时间，那么仅在那段时间进行监视可能就足够了；您只是在寻找趋势来帮助您集中精力进行故障排除.

The template's default sampling interval of 15 seconds should be good enough, provided you monitor long enough. If you have hour(s) of peak usage during the day, it may be good enough to just monitor during that time; you're just looking for trends to help you focus your troubleshooting.

PAI工具提供了针对IIS 5.0和6.0的分析器，但不是经典的ASP.您可以创建一个新的分析器(在PAL中称为阈值文件)以包括对ASP的分析.该代码太长了，无法在此处发布，但是，如果您有兴趣，请给我评论，我们会确定如何将所拥有的信息发送给您.

The PAl tool comes with analyzers for IIS 5.0 and 6.0 out of the box, but not classic ASP. You can create a new analyzer (called a threshold file in PAL) to include analysis for ASP. The code's too long to post here, but if you're interested, leave me a comment and we'll work out how I can send you what I have.

此外，如果您拥有Visual Studio企业版，则可以使用 Visual Studio Analyzer (VSA)可以跟踪所有ASP和COM调用.它可以很好地分析所花费时间的位置，并且您可以包括Perfmon计数器以进行监视，以查看系统级别的运行情况.

Also, if you have the Enterprise Edition of Visual Studio, you can use the Visual Studio Analyzer (VSA) to trace through all the ASP and COM calls. It does a pretty nice job of profiling where the time's being spent, and you can include Perfmon counters to monitor to see what's going on at the system level as well.

这篇关于监视Windows 2003/IIS 6.0中的ASP/COM +应用程序性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！