windbg定位WEB性能瓶颈案例一则

测试环境 

服务器:II服务器 

网站:门户网站

 

条件 

并发: 2000 

LoadRunner思考时间:1s

 

表现 

CPU:100% 对应w3wp进程 

WebService–>Current connections:2300 

DB:CPU 10% 无压力

 

压力降低后表现 

随着并发量下降,CPU 和 WebService–>Current connections 随着下降,随后恢复正常;

 

分析 

1)IIS的CPU达到100%,DB的CPU只有10%,瓶颈可能在WEB程序端; 

2)压力降低后,CPU 和 WebService–>Current connections 随着下降,并恢复正常,说明有等待,没有死锁;

 

DUMP文件分析 

1)用  !syncblk 找出等待资源,信息如下: 

 

2)切换到 91 线程看看它在干什么 

 

3)看看其他线程在干什么 ~* e !clrstack, 最后看到大部分的调用如下 

  

结论

明了了,在查找母版页的时候,申请了排它锁,其他线程需要等待当前持有锁的线程释放之后才能继续往下执行,形成了较长的队列,成为了瓶颈。

 

posted @   鸽子飞扬  阅读(697)  评论(0编辑  收藏  举报
编辑推荐:
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· .NET周刊【3月第1期 2025-03-02】
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· [AI/GPT/综述] AI Agent的设计模式综述
点击右上角即可分享
微信分享提示