性能测试目的:摸底,还是正式压测要达到最优
-
-
链路摸底,你可以认为:不设上限,就是为了拿到,在系统各项指标安全范围内(内存、cpu、数据库等等),比如接口能正常响应的最大值(接口没有错误、响应无非常明显的变慢等)
-
-
-
正常的压测,一般有一个预期值,比如说线上高峰期的3倍,达到了就算通过;和这种全链路的摸底不太一样
-
服务级别的性能测试关注什么:
1、承受的最大并发数,QPS是多少
2、TPS是多少
3、响应时间多长
性能测试的流程:
1、需求调研
2、环境准备
3、脚本开发
4、数据预埋
5、场景设计
6、场景执行
7、应用监控分析
8、瓶颈定位
9、瓶颈修复
10、回归验证
11、数据整理&报告输出
性能测试的场景设计:
1、被测交易或使用的脚本
2、延时策略
3、运行时长
4、加压策略
5、并发用户数量
6、执行时长
7、终止方式
8、资源监控策略
测试指标和测试模型是进行场景设计的前提和基础
根据被测系统的类型不同,可能测试指标的类型略有不同。
对于在线Web类的应用,测试指标一般包括:在线用户数、最优并发用户数、最大并发用户数、交易平均响应时间、目标TPS等等。
对于接口调用类的应用测试指标一般包括:目标TPS、平均响应时间等。
如何设计测试的不同场景的比例(测试模型如何设计):
1、新成立项目,需要开发人员进行预估之后进行调研讨论决定,测试中如果出现与实际应用场景不同,则进行调整到实际应用场景,来预估测试比例
eg:对于还未上线运营的新系统,我们一般会让应用的产品经理或负责人给出一个预估的比例;但是这个预估需要我们进行评估,不是随意的。对于一个以提供下单交易为主的应用,通常下单交易是占整个模型的较大比例,如果需求方提出的模型是查询比例较高,那么我们就有理由怀疑该模型的合理性。对于这种情况,我们建议选择几个常见的典型的模型来配合需求模型进行场景设计
2、老项目则通过某日线上的统计数据进行计算评估,这样更精准
eg:对于已上线运营的应用,我们一般会分析实际的交易数据来确定交易比例,这样会更加精准。例如一个应用对用户提供下单、查询、退款三个交易,我们通过DBA在线查询某日的交易数据总量为200000笔,其中交易下单160000笔、查询38000笔,退款2000笔,由此我们算出各交易的比例是80%、19%、1%,那么这个比例就是我们的测试模型。
1、被测接口or应用或使用的脚本:
测试脚本是测试场景的基础,通过实际使用场景设计测试脚本,提前进行环境准备和数据预埋。
2、并发用户数量或并发线程数:
并发用户数量和并发线程数量其实就是一个概念,并发用户:是虚拟用户,是压力测试工具使用进程或线程来模拟真实用户请求的一种方式。并发用户是每个场景提供压力的直接来源,场景不同并发用户数量的要求不同。
什么因素决定一个场景的并发用户数量呢?
a、平均响应时间(RT响应时间):执行一个请求从开始到最后收到响应数据所花费的总体时间
b、目标TPS:一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程
并发用户量 = 平均响应时间*目标TPS/1000
并发数 = QPS * 平均响应时间/1000
QPS是每秒的查询量,最大吞吐量:有两种计算公式:
QPS = req/sec = 请求数/秒
QPS = 总请求数 / ( 进程总数 * 请求时间 )
3、运行时长:根据不同的测试场景设计运行时长
场景设计 | 基准测试 | 负载测试 | 混合容量 | 稳定性 | 扩展性 |
运行时间 ps实际场景or开发评估 | 10~20m | 10~30m | 10~30m | 8*24h | 10~30m |
4、加压策略:并发用户以什么样的步调对应用发起请求
a、同时加压策略:不设计间隔等待时间,瞬间加压,来评估服务的瞬间负载能力
b、指定间隔时间进行加载策略(常用):根据生成环境的情况,设计并发用户的频率,来模拟真实的加压场景,直至达到峰值或超过评估的峰值
c、梯度加压:也是我们常用的一种用户加载方式,但是这种方式严格来说应该是一种梯度加压场景。该场景一般是预先设置几个并发用户的梯度,每个梯度执行几分钟,这样就可以通过一个场景的执行基本上找到应用的最大TPS
5、延时方式(三种方式):延时在场景中的作用就是为了精准控制TPS或降低当前并发用户数量下的压力。延时是上一笔请求完成对一笔请求发起之间的时间间隔
1、无延时:设置0延时,上次请求发送完成后马上发送下次请求
2、间隔指定时间:上次请求发送完成后间隔指定时间再发送下次请求
3、再指定时间内完成一次请求:即区间型的延时,这要求我们设置的这个时间要大于交易的响应时间,也就是说要保证交易响应时间在我设置的这个时间的区间内,否则就不能实现精准控制TPS的目标。在这个区间内,交易响应时间无论如何变化,只要不突破我的这个最大区间,那么TPS就是平稳的
6、用户终止方式:同时退出、间隔时间退出多少用户
1、同时退出(常用)
作用是:应用在持续一段时间的压力后如果突然压力全部释放了,那么这时的应用在理想情况下应该是怎样的?CPU资源应该从繁忙立即变为空闲,网络传输也大幅降低,磁盘IO降为0等等。不然,那就是有某种问题的存在了。这时候就需要分析导致资源不能释放的原因。
2、间隔时间退出多少用户
7、各种资源的监控方式
资源监控考虑的因素有:监控对象、监控工具、监控方法、监控数据的采集频率(根据测试场景的执行时长决定采集时间的间隔)
监控对象:
1、服务器资源使用情况:CPU占用(一般不超过80%)、内存空闲率(空闲20%左右)、磁盘IO、网络吞吐
2、数据库:TOP SQL、数据库锁等待与死锁、缓存区命中率等
3、JVM的运行情况:堆内存垃圾回收、线程状态、数据库连接池使用情况等