之前写过一篇性能测试新手误区（五）：如何提出一个好的性能问题，主要讲一个有效的性能问题应该是什么样的，其中提到了定位的问题。但是那篇文章只说了WHAT，并没有说HOW，只说tester要有明确的定位，却没提如何才能定位。实际工作中，我也总是接到这种问题，所以还是要写一篇关于方法的文章，来说说HOW TO DO。

　　以一个典型的WEB系统来举例，性能问题一般体现在客户端请求后的响应时间上。在性能测试过程中，即压力增大到某个程度后，响应时间指标迅速增长。但如那篇文章所说，这只能叫做一个现象，测试人员需要找到问题所在，HOW TO DO？

　　首先要搞清楚，客户端从发出请求直到看到终结果，共经历了哪些过程。如果绘制出一张完整的路径图，我们的问题必将定位到这张图中的某一点上。下面是我画的一个常见的WEB系统请求的流转过程。

　　客户发出一个请求，这个请求首先会到达中间件的监听端口，专门的监听线程负责接待它，并将它分配给一个空闲的HTTP处理线程。HTTP线程根据请求内容，去执行相应的程序代码，这里会涉及程序的内部资源，比如专用的线程、一些队列等，程序的内部也许还有多个组件，依然可以拆分。再往后，从中间件维护的数据库连接池中取出一个空闲连接，通过它来与数据库进行交互。数据库收到查询请求后，同样需要找到一个可用的执行线程，然后才能执行具体的SQL，这里又会牵扯到很多数据库的内部资源，如锁、缓存等等。

　　可以看到，从用户点击鼠标发出请求，到显示器上展现出结果，实际是经过了很多处理过程的，这里的每一个节点出现问题，都会导致我们终看到的“响应慢”现象出现（这里不考虑操作系统层面、网络层面等一些外层的因素）。

　　理解了这个过程，只需采取一些科学的方法即可逐渐逼近问题根源，那是层层剥离、不断排除。从实际经验来看，数据库端容易出问题，那么首先要对其进行验证。数据库的性能一般是直接体现在SQL的执行效率上，我们可以捕获到出现问题时所有执行过的SQL，看其耗时是否正常。如果判断数据库端没有问题，那么再来到中间件端，这里又可分为应用服务器本身和我们自己的程序，可以先看看容易验证的部分，应用服务器本身通常维护了一些线程池，很容易可以观察到它们的使用情况，如果这里没有发现异常，那么问题很可能出现在我们程序的代码内部。如果在某一点上发现了异常现象，不要急于断定这里是问题根源，而是要同时观察与之相邻节点的表现，一个节点的故障通常也会导致另一节点的异常。

　　一个很有效的排查手段是日志，在每一个节点上输出接收到的请求和处理结果的日志，通常都会很容易的发现问题。

　　大致思路是这样，总结起来其实很简单。一是要理解请求处理的完整流程，二是通过科学合理的方法去分析。

　　后推荐个比较典型的问题排查过程供大家体会，超级奇怪的“黑色10秒钟”。我自己也有一些这种很有代表性的分析过程，有时间整理好也贴上来。