【性能诊断】一、开篇

标签：

      在使用.NET进行快速地上手并开发出应用程序后，接下来面临的可能就是系统性能调优方面的问题，尤其是目前的系统大多异常庞大而复杂，性能问题的诊断与调优工作更显得无从下手。一般来说诊断调优工作需要广泛的知识与经验，不单单是代码或SQL的经验，还要对业务逻辑、系统架构设计、应用程序编写、操作系统、网络环境、各种侦测与监控工具、硬件等等，都有基本的了解，才能在复杂的系统中找到症结所在。

      记得以前看到过，微软的性能调校文件上标示着各种元素所占的百分比：之前的经验19%、解决问题的能力22%、是否有完备的顾问服务16%、产品的熟悉程度26%、计算机相关知识13%、运气4%，是的，即使你有超强的能力，还有4%的机会是无法控制的。

      由于本人做过一段时间专职的诊断优化工作，把性能问题的处理过程与一般的分析方法及工具整理出来，分享给大家，也是抛砖引玉，如有不足之处请大家见谅。

接收到项目现场的性能问题反馈后，我首先会问几个问题，有一个粗略的了解：

1. 是整体性的问题，还是个别模块、功能出现问题？
2. 是响应时间长还是不响应（挂起）？
3. 是所有用户反馈，还是个别用户？当时的在线用户是多少？
4. 是间歇性的还是持续性的，间歇性的间隔时间是多少？月底/年底？
5. 从什么时间（或事件）开始？出了什么报表、做了月结、调整了网络、更换了硬件等等

根据现场的反馈，我会使用（或让现场）不同的工具收集性能数据，以下是我的性能问题诊断工具箱：

一般的分析过程：

1、使用fiddler或浏览器自身的开发工具，识别性能瓶颈在客户端还是服务端（或网络）？

2、如果是请求响应时间较长？则从应用服务器或网络方面分析。

3、应用服务器端，主要分析是否有明显的SQL等待、阻塞？识别瓶颈在应用系统还是在数据库服务器？

4、如果是SQL阻塞，则分析DB的性能视图、AWR、DB服务器上的性能计数器等等。

5、如果SQL没有明显的阻塞，使用RedGate分析应用服务器线程或抓取dump使用windbg分析。

6、同时使用APP及DB服务器上的性能计数器，收集CPU、内存、磁盘IO等方面的数据。

7、如果以上都没有明显问题，则考虑网络因素，可以使用网络监测工具进行抓包分析。

后续我会分别就单功能、并发场景、客户端、网络等方面的性能问题进行逐一介绍，也会整理几个典型实战项目的分析过程，喝口水先。

【性能诊断】一、开篇

标签：

原文地址：http://www.cnblogs.com/zhaoguan_wang/p/4568922.html