在使用.NET进行快速地上手并开发出应用程序后，接下来面临的可能就是系统性能调优方面的问题，尤其是目前的系统大多异常庞大而复杂，性能问题的诊断与调优工作更显得无从下手。一般来说诊断调优工作需要广泛的知识与经验，不单单是代码或SQL的经验，还要对业务逻辑、系统架构设计、应用程序编写、操作系统、网络环境、各种侦测与监控工具、硬件等等，都有基本的了解，才能在复杂的系统中找到症结所在。
记得以前看到过，微软的性能调校文件上标示着各种元素所占的百分比：之前的经验19%、解决问题的能力22%、是否有完备的顾问服务16%、产品的熟悉程度26%、计算机相关知识13%、运气4%，是的，即使你有超强的能力，还有4%的机会是无法控制的。
由于本人做过一段时间专职的诊断优化工作，把性能问题的处理过程与一般的分析方法及工具整理出来，分享给大家，也是抛砖引玉，如有不足之处请大家见谅。
接收到项目现场的性能问题反馈后，我首先会问几个问题，有一个粗略的了解：
- 是整体性的问题，还是个别模块、功能出现问题？
- 是响应时间长还是不响应（挂起）？
- 是所有用户反馈，还是个别用户？当时的在线用户是多少？
- 是间歇性的还是持续性的，间歇性的间隔时间是多少？月底/年底？
- 从什么时间（或事件）开始？出了什么报表、做了月结、调整了网络、更换了硬件等等
根据现场的反馈，我会使用（或让现场）不同的工具收集性能数据，以下是我的性能问题诊断工具箱：
一般的分析过程：
1、使用fiddler或浏览器自身的开发工具，识别性能瓶颈在客户端还是服务端（或网络）？
2、如果是请求响应时间较长？则从应用服务器或网络方面分析。
3、应用服务器端，主要分析是否有明显的SQL等待、阻塞，识别瓶颈在应用还是在数据库？
4、如果是SQL阻塞，则分析DB的性能视图、AWR、DB服务器上的性能计数器等等。
5、如果SQL没有明显的阻塞，使用RedGate分析应用线程或抓取dump使用windbg分析。
6、同时使用APP及DB服务器上的性能计数器，收集CPU、内存、磁盘IO等方面的数据。
7、如果以上都没有明显问题，则考虑网络因素，可以使用网络监测工具进行抓包分析。
后续我会分别就单功能、并发场景、客户端、网络等方面的性能问题进行逐一介绍，也会整理几个典型实战项目的分析过程，喝口水先。
补充，并发测试或生产环境系统响应缓慢，一般来说会有两种表现形式：
- 一种是系统非常的忙，出现资源使用的瓶颈，表现为CPU高，可用内存数低，磁盘读写频繁等等；
这类问题需要找出产生瓶颈的模块、代码等（诊断应用最好是windbg、性能计数器和redgate结合使用，数据库使用性能视图和性能计数器），一部分原因可能是算法效率不高，另外也有可能是架构设计造成的（比如第三方组件选择、接口设计上没有提供批量算法等），如果技术实现或设计上没有优化和改进空间的话，只能通过升级硬件或横向扩展解决； - 另一种是出现系统的死锁、阻塞，程序的某行代码在一直等待某个事件的发生，表现为CPU占用率低，系统运行平稳，但是程序响应缓慢；
这类问题一般都是具体的程序设计或算法实现问题造成的。
补充2，系统稳定性问题，一般要关注操作系统的日志（eventvwr.msc）和数据库的ErroLog日志。
