qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

性能问题的分析定位方法

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

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

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

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

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

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

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

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

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

posted on 2013-06-09 11:50 顺其自然EVO 阅读(301) 评论(0)  编辑  收藏 所属分类: 性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜