上一篇我们简单的对客户前端和数据库后端的性能问题进行了定位，如果排除了这两块，问题基本就确定在应用服务器上。但是我们往往对应用服务器，或者说应用程序的性能最陌生，一旦出现性能问题往往有无所适从的感觉，虽然我们的对应用程序的代码最熟悉。
原因有这么几项：
- 系统庞大、业务复杂时，如果从代码审查入手，主观性因素影响较大；如果在各处代码中增加log统计响应时间，很不方便、也不科学，且工作量很大；
- 自己维护的代码调用了其他模块的接口，无从下手；与其他模块同事交流时，描述复杂、沟通困难；
- Oracle环境不方便跟踪SQL脚本的执行记录，Sqlserver虽然能够做到到，但跟踪到其他模块的SQL也不知道是哪个方法调用的；
基于这些原因，另一个强大的工具诞生了---ANTS RedGate Performance Profiler
下载地址：http://www.red-gate.com/products/
RedGate与VS自带的分析工具对比
Visual Studio Performance Profiler
Visual Studio 分析工具的采样分析方法按设置的时间间隔中断计算机处理器并收集函数调用堆栈。
1.专用术语太多，分析报告不易理解
2.操作复杂、与VS集成
3.不能将SQL执行、文件操作同步抓取分析
RedGate Performance/Memory Profiler
RedGate基本工作原理是在.NET编译出的IL代码里放入钩子用来记录时间，然后通过直观的界面显示出哪部分代码耗能最大。
1.可视化界面、操作简洁，直观的展现系统的性能响应与内存分配情况；
2.能够捕捉到SQL脚本与执行时间，SQL与.NET代码关联切换；
3.可以针对指定线程进行特定分析，便于快速定位问题；
使用示例
启动Performance，注意再测试时使用新的Profile端口。
使用鼠标选中指定时间区间后，redgate自动会进行分析，缺省我们看到的是Call Tree视图，此处我们注意三点：
- Call Tree显示该时间段内进程的线程调用堆栈和对应的CPU消耗及方法调用次数；可以推测出循环、递归等代码；
- 此时我们看到的是CPU执行时间占比（或执行时间），不包含SQL执行、网络、文件等IO阻塞的等待时间；
- 如果是debug的dll又有对应的pdb文件，选中指定方法，可以直接查看到源代码；
切换到Method grid， 按照方法执行的总时间倒序，不考虑调用关系；利用隐藏指定命名空间（或仅显示指定命名空间），可以方便查找并突出问题；
Database calls视图 展示所有的数据库SQL访问，缺省按执行时间倒序，SQL脚本后面有.NET图标，可以快速定位到该SQL的程序调用堆栈；Call tree中的SQL脚本图标，同样可以快速返回到Database calls界面；
另外，为选中区域命名，方便后期分析，提高工作效率；当后台处理较复杂，如使用了多线程，或者一个功能对应很多http请求时，可以按指定线程分析问题；
介绍类的内容就不做过多的介绍了，下一篇会以一个例子，使用redgate诊断一个刚接触貌似很诡异问题。
