菜鸟的性能测试之路（二）
（怕你们看睡着了，先上图）
本大纲
要提到性能测试，可能首先就会想到LR或者Jmeter的工具；然后会联想到压力测试；接着还会关注vUser、TPS、请求时间、事务响应时间、吞吐率等性能指标。不过这一次，我首要focus在性能缺陷的分析、定位方面，把工具类先放一放。
接下来我借助行业大牛的经验和我以往踩过的坑总结一下，什么是性能缺陷、如何分类以及分析方法等等。
什么是性能缺陷？
我自己的理解是，性能测试的响应时间或者是资源的耗用，没有达到预期的性能指标，就是性能缺陷。比如像并发的错误、死锁、内存泄露等都属于性能缺陷。
如何分类？
性能缺陷从分类上，可以分成两大类：一种是忙不过来，系统处理不过来要处理的请求；另外一种是系统怠工，各方面资源都很清闲，但是它就是不干活。
如何分析？
针对这些性能缺陷，我结合了一下自身所踩过的坑和大神们分享的经验，介绍一种是由下到上的分析方法，通俗地讲，就是剥洋葱的方法，也可以叫排除法。首先从系统的硬件问题去分析，然后是操作系统，数据库，中间件，后端和前端的应用程序。为什么说这是自下而上的分析方法呢？因为请求是反方向的，例如一个B/S的请求，首先是经过前端也就是系统的页面，然后是web服务器，应用服务器，再到数据库服务器，之后磁盘读取数据通过网络再传输回去，刚好就是一个逆向的过程。要分析好性能缺陷，就要要求工程师既需要有丰富的知识，也要相应的方法。目前互联网或者银行的系统，都是越来越复杂；而且很少是孤立的，很多都是多个系统交互在一起，涉及到系统的架构也很复杂，包括前端、后端、应用服务器、数据库等等。面对复杂的系统，要一层一层地去剥离，把一个大的系统分解成一个个小的单元，一个一个去排除。同样的，编程语言里的一些复杂的计算，也可把它分解成一个个小的单元和步骤，逐步去解决。
这里举一个案例，是某银行的业务系统，这个系统的架构是基于java语言开发的应用系统，采用Weblogic作为应用服务器，后台数据库是用的Oracle，这些服务器是部署在Linux系统的环境上。因为银行系统对于安全性的要求是很高的，为了保证系统的安全与稳定，增加了流量控制的功能。当请求量突然爆增，流量控制可以设置最大的并发流量，这样就能保证系统不会轻易崩溃。针对该银行进行相应的业务分析、架构分析，编写了测试方案和用例，录制了相关脚本。
测试策略分成了以下几步：第一步，基本测试。也就是说，针对某一个用户进行性能测试，压测5分钟，单线程去访问系统，而这时候对于系统的压力是非常小的。这一步目的是为了获得系统在没有压力的情况下的一个基准，基础的响应时间，这就可以为下一步性能拐点做一个对比。第二步，负载测试。对单个交易，多个用户进行并发测试。目的就在于验证这个系统，在这种并发请求的情况下是否会出现并发错误或者数据库锁。第三步，容量测试。按一定的比例去配比，一定的梯度去施压，直到系统出现拐点，系统处理不过来请求，响应时间变长，资源占用达到很高。第四步，稳定性测试。采用一定的压力，长时间去运行。目的是为了验证系统长时间运行的的能力，是否会存在内存泄露；大量数据的请求状态下，是否会出现数据库的查询会变慢。
测网速
测试过程中发现，在基本测试时，获得了各个交易的基准时间；在负载测试过程中，发现交易也算正常（10个并发用户，响应时间只是有点略高但不影响）；容量测试时，第一梯度使用10个用户的并发量，响应时间也正常；第二梯度时有异常了，显线性增长，出现性能瓶颈。接下来就要分析了，回到开始提到的那两种情况，分析是属于系统忙不过来还是怠工情况。这里采用排除法，首先分析网络，利用ping看网络延迟，网卡的流量，是否达到网络瓶颈。分析下来，发现延迟很小，因为采用了千兆网卡，网络通畅。操作系统层面分析应用服务器和数据库资源耗用，通过分析发现，应用服务器和数据库服务器的CPU资源都在10%左右，内存使用量也比较小，没有出现频繁唤入唤出的现象。进一步分析I/O（包括网络和磁盘），发现读写比较小，因为请求量比较小。那么综合分析下来，发现问题并不属于系统忙不过来，而是怠工问题。
出现怠工，一般是由于排队，或者堵塞问题。首先可能是入口，网络连接口。请求很多，但网络连接达不到。还有可能是应用服务器受到高并发，就可能出现死锁、线程锁的问题。数据库可能会存在两条语句同时update一个表，出现锁的现象。接下来依然采用排除法，先看数据库有没有这种锁。Oracle自带有AWR报告，可分析Oracle运行现状，分析有没有出现线程锁、等待等。分析下来是没有问题。接下来是weblogic端，看控制台，或应用日志，去搜索deadlock、wait、lock的现象。分析下来也没有问题。然后是前端，连接数（connection），发现连接数很少。在并发量达到几万的时候，并发连接数只有几十个，初步定位错误原因是前端的请求量，也就是连接数出现问题。然后就是和开发一起分析，定位连接数是瓶颈，是因为流控触发了（non-limit）。此前在测试环境操作的时候和开发沟通过，本次测试主要是测容量，流控被关掉了。但奇怪的是，流控是被关了，但结果看来流控是被触发了。验证很多次后，问题还是依然可以重现。无奈之下尝试重启应用服务器和数据库服务器，结果奇迹发生：重启后，现象消失。分析下来，有可能是开发改了配置文件后，没有重启应用服务器和数据库服务器，导致流控文件没有生效。
是的，有时候分析过程就是很曲折的；也就印证了那句名言：眼睛往往所看到的，不一定是真实的。
读更多的好书，拍更美的照片，写更酷的代码，遇见更有趣的人，愿望是实现从IT菜鸟到全栈工程师的蜕变。
