系统性能分析(找出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揪出来！
待续......