性能实战之测试执行阶段

性能测试准备阶段结束后，就来到了测试执行阶段。

测试执行阶段

这个阶段算是性能测试最有魅力的，围绕着场景执行与调优，是大展身手的地方。

场景为什么要跟调优放在一起，因为从实际执行中来看，它们是密不可分的。

场景执行

场景就类似功能测试的用例，有着对应的目的，功能测试的用例是为了发现缺陷，而性能场景就是为了发现性能瓶颈。

第一篇需求分析中说到性能场景分为了4类：基准场景、容量场景、稳定性场景、异常场景。而每一个场景的目的不一样，可以依次按照顺序执行。

基准场景

基准场景是需要首先执行的，和我们常见的性能测试很相似，本质就是单接口的压测，目的是找到单接口或单业务的最大TPS。

第一步：设置场景的执行参数，以jmeter为例，主要包括线程数，Ramp-Up时间，场景执行时间等，如下图

注：我一般以5分钟递增，5分钟持续做为正式场景跑，可以根据时间情况调整。

那么如何确定线程数？先跑一次单线程的结果，根据平均响应时间计算所需的线程数 = TPS*RT/1s=800*0.172s/1s =137.6，我们可以往上取150试试。

第二步：执行场景，观察收集结果，我这边搭建了jmeter结果收集平台，可以实时看，如下图

注：观察jmeter的TPS与响应时间曲线，以及服务器的全局监控情况，然后分析并准备接下来的动作，如果有事务报错的情况，优先解决。

第三步：根据场景执行情况，调整执行策略，常见如下

• 情况一：TPS上不去，资源够用
• 情况二：TPS上不去，资源不够用
• 情况三：TPS能上去，资源不够用

这里贴一个首页单接口场景，前面需求分析阶段提到至少要满足800TPS，目前TPS 2.6K，RT 33ms已经达到了。

再看看应用服务器的资源利用率，CPU 70%，内存 50%，网络带宽约100Mb/s。

TPS目标达到，资料利用率不算低，那就暂时不动它。

再贴一个单接口场景，能看出TPS 约70，RT 约600ms，TPS未达到，资源也没有利用上。

应用服务器的资源利用率，CPU 4%，内存 50%，网络带宽约2Mb/s：

 这时TPS与资源都没有达到目标要求，这种就需要先解决，进入场景调优。

因为调优是无止境的，所以在控制成本下，先解决优先级高的接口。 

场景调优

首先场景调优就是对场景进行性能分析，再找出瓶颈并解决的一个过程。一般情况下场景执行跟调优都是交叉进行的。 

如何进行性能分析呢？可参考高楼老师的“RESAR性能分析七步法”：

这七步分析逻辑就是从表现开始，找出证据，再一步一步的深入定位，找出问题实质的过程。

压力场景数据分析

针对上面的登录场景，首先我们看TPS，和响应时间曲线：

发现在时间在14:14与14:15中间后，随着压力的增加，响应时间也随着增加，而TPS也不再增加，这时就已经出现了性能瓶颈。

分析架构图

架构图是用来分析流量的路径，这里非常简单：

压测服务器——〉服务器A（nginx，zuul服务）——〉服务器C（用户服务）——〉网关服务器B（mysql，redis）

拆分响应时间

可以使用日志打印的方法，也可以安装APM链路监控工具，主要是确定时间消耗在那个链路上。

全局监控分析

这里我跳过了上一个步骤，因为全局监控中我看到了数据库的服务器压力较大，如下

 进入数据库所在的网关服务器A，使用top命令查看，发现是mysql占用比较大，因为user表有10万条数据，猜测瓶颈在这。

 

定向监控分析

于是对mysql进行定向分析，其实Prometheus也可以监控mysql，可以直接分析场景执行时的mysq资源计数器。

我这里直接问开发要的sql，因为登录就是查询用户，如果新用户会进行插入sql。而我的场景用户数据都是老用户，所以只是查询，猜测这里出现了问题。

判断性能瓶颈

为了验证猜测是否正确，直接查看sql的执行计划（expalin），通过type列可知（忘截图了），没有用到索引，数据量小还好，数据量一大就非常明显。

确定解决方案

所以直接加上索引，如下

再次跑一下场景，结果如下：

13:42之前由于是老用户所以不用插入，TPS高，后面全是新用户，需要插入数据，即新用户的TPS达到了1.6k，比之前提升了十几倍，索引不愧为性能提升利器。

这里大家可能会发现，不同的测试数据对TPS影响很大，于是我还做了全部新用户、新老用户比1:1的场景。

执行情况归档

上面只是一个单接口的场景，实际上一整遍流程下来，我还遇到了其他瓶颈，后面有机会单独说说。

我会把整个执行与调优的过程都记录下来，方便后续追溯。

其实基准场景除了执行各单接口的场景外，还要进行业务级场景，比如多个接口一起组成的业务操作场景（比如登录，包括获取验证码和登录两个接口），而每个场景都可以按照这个流程来实施，最后使场景到达TPS目标。

容量场景这里我没写，后续补充，至于异常和稳定性场景，这次由于时间原因，也没有考虑，下期就是报告结论阶段了。