WEB系统性能问题的分析定位方法

之前写过一篇性能测试新手误区（五）：这是性能问题么，主要讲一个有效的性能问题应该是什么样的，其中提到了定位的问题。但是那篇文章只说了WHAT，并没有说HOW，只说tester要有明确的定位，却没提如何才能定位。用流行的话说就是不接地气，有点水：）

实际工作中，我也总是接到这种问题，所以还是要写一篇关于方法的文章，来说说HOW TO DO。

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

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

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

如果你熟悉tomcat和mysql，就知道上面所说的中间件的监听线程对应的是tomcat的connector，HTTP处理线程对应的是engine中的线程池（如下图），数据库的执行线程可能对应的是mysql的InnODB引擎线程（而不是connection）。对系统的结构了解的越深入，这张流程图绘制的就越细致和准确。

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

理解了这个过程后，只需采取一些科学的方法即可逐渐逼近问题根源，那就是层层剥离、不断排除。

从实际经验来看，数据库端最容易出问题，那么首先就要对其进行验证。数据库性能的外在体现一般是在SQL的执行效率上，我们可以捕获到出现问题时所有执行过的SQL，看其耗时是否正常。

如果确实很慢，我们需要判断问题是发生在数据库入口（比如获取不到connection）处还是内部，是内部的执行线程不够，还是在一些资源上发生了争用。

如果判断数据库端没有问题，那么再来到中间件端，这里又可分为应用服务器本身和我们自己的程序，可以先看看最容易验证的部分，应用服务器本身通常维护了一些线程池，很容易可以观察到它们的使用情况，客户端的请求是否能够到达中间件，是否有可用的处理线程。

如果这里没有发现异常，那么问题很可能就出现在我们程序的代码内部。依然是上面的拆分方法，同开发人员共同完成定位。

一个很有效的排查手段就是日志，在每一个节点上输出接收到的请求和处理结果的日志，通常都会很容易的发现问题。程序内部也可能需要利用stub或者mock。

需要注意的一点是，在某一点上发现了异常现象，不要急于断定这里就是问题根源，而是要同时观察与之相邻节点的表现，一个节点的故障通常也会导致另一节点的异常。

大致思路就是这样，说起来其实很简单。一是要理解请求处理的完整流程，二是通过科学合理的方法去分析。但是要做到理解处理流程，是需要经验和技术积累的，要很全面的去学习多个层面的知识，这其实也就是性能测试工程师最大的特征。掌握到什么程度，问题就能定位到什么程度，如果你只知道系统可分为中间件和数据库，那你也就只能定位到这个层面。

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