如果某个东西正在使单线程程序占用,比如10倍,那么就可以在其上运行一个分析器.您也可以通过"暂停"按钮暂停它,您将看到它正在做什么.
即使它比它应该慢了10%,如果你停止它多次,不久你会看到它反复做不必要的事情.通常问题是在堆栈中间某处不是真正需要的函数调用.这不能衡量问题,但确实找到了.
编辑:反对意见主要假设您只采取1个样本.如果你是认真的,请采取10.任何一行代码,导致一定比例的浪费,如40%,将平均出现在该部分样本的堆栈上.瓶颈(单线程代码)无法隐藏它.
编辑:为了表明我的意思,许多反对意见的形式是"没有足够的样本,所以你看到的可能完全是虚假的" - 关于机会的模糊观点.但是,如果任何可识别的描述,不仅仅是在常规或常规活动中,在30%的时间内有效,那么在任何给定样本上看到它的概率是30%.
然后假设只采集了10个样本.在10个样本中看到问题的次数遵循二项分布,并且看到它0次的概率是.028.看到它1次的概率是.121.2次,概率为.233,而3次则为.267,之后下降.由于看到它少于两次的概率是.028 + .121 = .139,这意味着看到它两次或更多次的概率是1 - .139 = .861.一般规则是,如果您看到可以修复两个或更多样本的内容,则值得修复.
在这种情况下,在10个样本中看到它的机会是86%.如果你是14%没有看到它的人,那就去做更多的样品.(如果样本数量增加到20,那么两次或多次观察的几率会增加到99%以上.)所以它没有经过精确测量,但已经准确找到了,重要的是要了解它它可能很容易成为分析器无法实际找到的东西,例如涉及数据状态的东西,而不是程序计数器.
我对一般的网站运营都很陌生.我熟悉桌面应用程序的统计分析器,但不确定如何开始分析网站,因为存在许多额外的潜在瓶颈,我不确定哪些分析器可用于网站.
我环顾四周,在其他问题上看到了有用的建议,但我不确定它们是非常完整的解决方案.主要建议是天蓝色的性能指标和这个答案的建议.
总结它们是:使用firebug单独确定渲染时间和加载时间,以便可以判断是否存在渲染问题或服务器问题.
如果服务器端:测试一个小的静态页面,就像一个带有单个gif的页面.如果这很慢,则会出现CPU问题.否则,可能是IO绑定或数据库性能有问题.
可以使用性能计数器来检查服务器方面,例如:内存垃圾收集tcp/ip问题发送/接收的字节请求,排队,拒绝请求等待时间,处理时间
从我天真的角度来看,这个列表中似乎缺少的一些东西就是对传统桌面应用程序的分析,即堆栈看起来像什么时间的百分比(即我们花费时间在哪些功能,以及什么上下文).另一个缺失的项目是分析数据库性能,这似乎在天蓝色上可能与在本地环境中不同,特别是如果开始处理缩放.另一个是花在第三方服务请求上的时间,尽管可以用天蓝色的性能计数器(？)来完成.
我为这个问题的天真性质道歉.我在这里找不到哪些工具和方面来描述一个天蓝色的MVC asp.net网站,你会对上面的列表做出哪些改变？