在 Web 应用程序压力测试期间记录性能时,我应该在 Windows 性能监视器中使用哪些计数器?

发布于 2024-07-26 14:41:33 字数 109 浏览 1 评论 0原文

我正在设置 Windows 性能监视器以在运行 MS Web 应用程序压力工具时记录 Web 服务器上的活动。 我应该选择哪些计数器才能最好地了解瓶颈、性能和响应缓慢等情况?

干杯

I am setting up windows performance monitor to log activity on a web server while running MS Web application stress tool. Which counters should I choose to give me the best picture of where I have bottlenecks, slow performance and response etc?

cheers

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

纵性 2024-08-02 14:42:16

Windows 性能工具 perfmon 可能不会告诉您很多有关瓶颈的信息,但它可以帮助您确定对系统施加的负载的影响,并且如果运行足够长的时间,很可能会告诉您如果你有资源泄漏。

我的基线项目:
流程的所有流程项目
处理器
内存

对于采样周期,我倾向于将预期运行长度的目标设为 100-200 个样本。

下一组问题将非常针对您的应用程序,以确定您的需求:
.Net 和 ASP 对象(如果适用)
网络对象(如果您怀疑网络接口有问题)
如果您怀疑或想要调查不同负载下发生的磁盘活动量的影响,则磁盘 IO。

与收集数据同样重要的是审查的时间。 对于第一次查看,值得花一两个小时来调出每个计数器并注意趋势。 一旦您对柜台有了更多的经验,您就可以专注于特定的项目。 我总是倾向于检查是否存在泄漏:
处理计数、线程、私有内存、可用系统页表条目、数据库连接计数(如果可以获得)。

不要忘记查看整个系统,而不仅仅是您的网络服务器。 应用程序问题可能会出现在任何链接的(直接或间接)资源上。 仅仅因为其他失败或缓慢并不意味着它不是由您的应用程序引起的。

The windows performance tool, perfmon, is probably not going to tell you a lot about where your bottlenecks are, but it can help you determine the impact of the load you are putting on the system and if run long enough, is likely to tell you if you have resource leaks.

My baseline items:
All Process items for the process
Processor
Memory

For sampling period, I tend to target 100-200 samples for the length of the expected run.

The next set of questions will be very specific to your application to determine what you need:
.Net and ASP objects if they apply
Network objects if you suspect problems on the network interface
Disk IO if you suspect or want to investigate impact how much disk activity is going on at different loads.

As important as collecting the data is the time to review. For first time views, it's worth taking an hour or two just to bring up each counter and notice the trends. Once you've become more experienced with the counters you can focus in on specific items. Things I tend to always review for leaks:
handle counts, threads, private memory, free system page table entries, data base connection counts if you can get them.

Don't forget to look at the whole system and not just your web server. Application issues can show up on any of the linked (directly or indirectly) resources. Just because something else fails or is slow doesn't mean it wasn't caused by your application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文