如何有效的进行性能测试

为什么要做性能测试

    现信也科技用户体量及资金流量较大，业务场景复杂。服务多一秒的延迟，就可能会造成上成百上千的标的逾期，可能导致上百万的资金损失。故在现有的背景下，服务上线前性能测试是非常有必要的。因性能测试在服务上线前就能有效的预估：服务是否达到快速响应的要求，服务是否存在资源死锁、内存泄漏等问题，服务是否能满足业务未来的预期增长。

    基于此，什么是性能测试？性能测试类型有哪些？性能测试工作如何开展以及有哪些好用的性能测试工具。本篇文章就跟大家谈一谈。

性能测试定义

性能测试通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

性能测试类型

    根据不同的压测需求，性能测试可分为如下几种类型

验收测试：压测是否满足指定预期。例如某接口最大处理能力是否达到100TPS，响应时间在500ms以内。

基准测试：在标准压测条件下，进行性能测试。查看系统运行时各项指标。作为后续测试标准。

负载测试：指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。

压测测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。

稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题

配置测试：如何用最省的资源，达到最优的性能，最好的支撑业务

测试场景

    性能测试场景主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较。

    不同的测试场景用途及特点如下：

作用	主要用途	典型场景	特点	常用类型
能力验证	关注在给定的软硬件条件下，系统能否具有预期的能力表现	在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？	a)要求在已确定的环境下运行b)需要根据典型场景设计测试方案和用例，包括操作序列和并发用户量，需要明确的性能目标	a)负载测试  b)压力测试  c)稳定性能测试
规划能力	如何使系统具有我们要求的性能能力	某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？	a) 它是一种探索性的测试b) 常用于了解系统性能和获得扩展性能的方法	a) 负载测试  b) 压力测试  c) 配置测试
性能调优	主要用于对系统性能进行调优	某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？	每次只改变一个配置，切忌无休止的调优	a) 并发测试  b) 压力测试  c) 配置测试
缺陷发现	发现缺陷或问题重现、定位手段	某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露	做为系统测试的补充,用来发现并发问题，或是对系统已经出现的问题进行重现和定位	a) 并发测试  b) 压力测试
性能基准比较	常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁	很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标

测试流程

性能测试流程按照不同的测试阶段可分为：：调研→准备→执行→分析→报告

• 调研：所谓谋而后动，做事之前事先谋划好所有的事情。往往会达到事半功倍的效果。
• 准备：明确准备好所有的测试事项，跟所有人达成一致。是做事的前提。
• 执行：如果前两步做好了，执行是最轻松的一个环节。
• 分析：分析是经验和技术能力提现，多学多做多总结。不仅见“猪”跑，也要吃“猪”肉
• 报告：如果以上都做好了，报告就水到渠成了。
  

本期重点聊一下性能测试调研和性能分析。

    1.性能测试调研

    以上内容在条件允许的情况，在性能测试开展之前尽量跟相关方聊清楚

    调研内容基本都可以通过沟通得知明确内容，其中指标计算需要重点说明一下。不同的测试场景需要不同的计算规则。

场景一：

有明确的指标要求，比如：某服务TPS必须达到100TPS，响应时间在500ms以内。那测试时按照这个目标进行就行了。

场景二：

历史数据显示，某服务的日交易量达到100万笔，90%响应时间在500ms以内。未来业务增长量为30%

根据2/8原则粗略的计算方式是：峰值TPS=（日交易量*80%/日交易时间*20%）*（1+30%）=[(1000000*80%)/(60*60*24*20%)]*(1+30%)≈60笔/秒

场景三：

没有历史数据或业务增长量估计。则可以通过负载测试，多轮次压测。得到目前现有服务最大处理能力是多少。为实际业务的放量做为参考。

负载测试时，发起压力与实际处理能力的对比曲线如下：

从上图可以看出。当发起线程为100时，实际最大处理能力为1800TPS。此点就为本服务最大处理能力的拐点。后续发起线程再大，处理能力也不会增加。此时即可反馈业务部门，在此压测场景下，我方可提供的最大能力为1800TPS。如后续业务扩展超过此吞吐量，则需考虑增加机器或性能调优。

    2.性能测试分析：

如何有效的准确分析性能问题，三多箴言“多学多做多总结”。整理了三个经常遇到的性能问题，共大家参考。

问题一：内存泄漏

如上图所示：堆内存持续上升无回收情况。明显存在内存泄漏。（工具jconsole）

问题二：响应时间过长TPS不达标

通过调用链的耗时抓取，可明确定位具体什么方法耗时较长，如上图所示。（工具Jprofile）

问题三：吞吐量不稳定：

    此类问题要根据具体背景思考具体解决方案，本次出现此问题的原因及解决思路为：

现象描述：

1. 只是读取MQ队列消息时，各资源使用情况正常以及TPS波动很小（如上图1、3、5部分）
2. 但是在有消息写入MQ队列时，读取消息的TPS开始下降且下降到几乎为0（见上图2、4部分），各资源使用情况波动也很大。

问题分析：

1. 通过观察压测统计数据波动图、MQ后台动态实时监控及应用线程实时监控确认读取消息处理能力下降是由MQ写消息造成。
2. 进一步分析是确定当前MQ队列读写消息的配置连接为同一个，即写入MQ队列消息时会锁定连接不能读取MQ队列消息。原先Spring-amqp 的配置为cache-mode=”channel”

解决处理：

1. 修改配置信息，把读写消息连接配置连接分开。修改后 Spring-amqp 配置为cache-mode=”CONNECTION”。
2. 重新压测后，TPS处理正常
   

性能测试工具

    工欲善其事必先利其器，这里简单介绍几款目前市面流行的几种性能测试工具。具体用法网上各种教程就不一一赘述了。

• 压力发起工具：

工具名称	适用场景	优点	缺点	开源
Jmeter	简单并发、组合业务流、CSV变量导入等	扩展性高、易上手、功能全	大并发下性能不稳定	是
LoadRunner	支持几乎所有压测场景，支持IP欺骗	专业、稳定、高效、场景支持全面，支持IP欺骗	收费且贵	否
ab	单个接口性能测试	简单易用	扩展性低，无法进行业务流的性能测试	是
PTS	支持单接口或业务流	无需搭建维护，集成在阿里云	收费且不如LoadRunner	否

注意：工具只是性能测试的一种手段，不等同于性能测试。

• 监控分析工具：

工具名称	作用	优点	缺点	开源
Nmon	系统级别资源监控	免安装、可视化报表	无法精确到应用级别	是
Zabbix	系统级别资源监控	分布式，可视化报表，页面化	需安装	是
Jprofile	应用级别资源及调用链监控	可视化、精确到方法级别	收费，需安装	否
jconsole	应用级别监控	精确到应用级	界面难看，监控范围狭隘	是
MoNyog	Mysql数据库监控	实时监测MYSQL服务器，查看MySQL服务器的运行状态	只支持支持MySQL、MariaDB等	否

性能测试经典案例

理发店模型

    在我们的这个理发店中，我们事先做了如下的假设：

1. 理发店共有3名理发师；（系统资源、服务器）
2. 每位理发师剪一个发的时间都是1小时；(处理时间)
3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。（用户可以容忍的系统响应时间为3小时，超过这个时间用户可能会重新请求或者不再请求）
   

通过上面的假设我们不难想象出下面的场景：

场景一：

当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

场景二：

当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

场景三：

很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时； 

    从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。（当并发用户数小于最佳并发用户数时，随着用户的增加，响应时间并不会增加，只是系统资源利用率增加了）

    当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

 场景四：

不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。（当并发用户超过最佳并发用户数，随着用户的增加，响应时间会变长）。

 场景五：

在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

场景六：

假设这次理发店里一次来了10位顾客，根据上面的推算，必然存在一位顾客的“响应时间”为4个小时，而之前我们又做过假设3小时已经是顾客忍耐的极限了，所以这个顾客会因为无法忍受等待时间而离开理发店。

通过以上6个场景我们可以得出以下结论：

1. 理发店每小时最多对3位顾客进行理发（最佳状态）
2. 顾客最多等待3小时，如超过，将离开理发店（最大忍耐限度，响应时间最低要求）
3. 进来的顾客最多为9位，不会出现顾客离开（最大边界值）
4. 进来顾客超过3位时，每个顾客在理发店的时间是不太一样的（排队有先后的，这表明没有绝对的并发）

以上都是在最理想的状态下，设计的场景。实际情况可能会出现各种复杂的情况和变化。有兴趣的同学可以延伸扩展思考下。这里提供几个思路：

1. 理发店的熟人情况，理发师和顾客很熟（同一参数大量请求缓存问题）
2. 理发店业务扩展，烫染业务、美容业务（不同的服务器提供不同的服务）
3. 招聘更有能力的理发师（更好的服务器配置，可以提高更高吞吐量）
4. 招聘更多理发师（用机器数量，提高实际吞吐量）
5. 线上预约，到时提醒（预约）
   

后话

       在如此高速发展的互联网时代。基本功能的完善已经无法满足越来越挑剔的用户。服务稳定的快速响应在未来会越来越受大家重视。作为从事科技行业的同学们，期望在写代码时、在做测试时、在规划服务器时，都保有一颗高性能的“心”。