This is a wonderful world

去自己想去的地方,呼吸那里的空气,贴近那里的土地,认识那里的人们......

导航

系统性能分析(找出trouble maker)

老听到客户抱怨“你的系统很慢啦!”做为无所不能的设计者,该这么解决这个问题呢? 
第一问题:系统慢在哪了?这时候有两种情况:
1.客户明确的抱怨某个功能很慢。OK,这种问题容易解决,调出这个功能的Unit test函数来(应该不会没写单元测试吧?:),如图所示:



单击“Create Performance Session”,创建一个Performance Session。



单击Launch的按钮,Performance Session会自动创建一个性能报告,包括了:最经常调用的函数,函数的执行时间,函数列表,程序调用堆栈。是不是很神奇?


调用堆栈段:


一旦知道哪些函数调用最慢,接下来就是修改代码咯(也许是tunning DB)。

2.整个系统很慢,你不知道问题出在哪了?
整个系统很慢?压力测试是怎么做的?!!呵呵,说笑了,我们一起找出问题根源。先打开Performance Explorer, 选择Web项目:



然后输入你要测试的URL,要注意的是Profiling Method选择Instrumentation。Instrumentation方法下Performance Explorer只探测你的应用程序,不会记录一大堆.net类库函数的调用。我想在大多数情况下,我们不关心.net类库的运行性能,因为无法改。



生成的项目如下:


接下来启动测试,模拟用户输入,让Performance Explorer捕获测试数据。



注意分析程序的调用的Call Tree:第一列是调用函数名,第二列是调用次数,第三列是耗时。导致系统运行缓慢的坏孩子在哪?那些调用较多同时又长时间运行的就是啦!把他们拖出去毙了,系统就活了。

当然,强烈不建议在production计算机上运行这样的调试。第一,影响正常运行;第二,你不会想在生产计算机上装个VS2005吧?(Profiling 使用探针技术,似乎没有远程插入的功能) 正确的做法是备份一份系统和数据到测试服务器上,在测试服务器上运行。

附:在Performance Explorer这个漂亮baby诞生之前,我们是怎么做性能分析呢:
1. 在系统的每个方法中加入Traceing,在问题发生时打开,在问题解决后关闭Traceing。缺点很明显:非业务功能代码不合时宜的出现在许多方法中。
2. 使用依赖注入。例如Elib3.1中在方法头加入log标签。缺点也很明显,因为每个对象是动态构造的,造成系统性能损失。

第二个问题:系统什么时候慢?有的系统有的时候快,有的时候慢,例如晚上9:00开始就特别慢?是网络问题?是设计问题?是磁盘问题?不要瞎猜了,下篇我们就把trouble maker揪出来!
待续......

posted on 2007-06-11 17:02  shyuan  阅读(4099)  评论(12编辑  收藏  举报