高级性能测试系列《35.普通性能场景、负载测试性能场景》

目录

• 一、普通性能场景
  • 1.继续
  • 2.调度器
  • 3.场景
• 二、负载测试性能场景
  • 1.完全不知道项目的性能瓶颈范围时，我们怎么设置？
  • 2.已经找到一个范围20-30了，怎么设置？
• 三、脚本链接

一、普通性能场景

1.继续：

如果在请求的过程中服务器报错了，默认是让它继续。做性能测试，大量的并发用户向服务器发起请求，请求的过程中，服务器可能偶尔出错。

这种出错的频率非常低的情况下，没问题。如果对于产品的准确性，要求是99.9%，那么0.1%的报错是被允许的。

如果对于产品的准确性，要求是99.99%，那么0.01%的报错是被允许的。允许有一定的报错，但是这个报错的频率不能很高。

但是出现连续的这种报错，就有性能问题了。

2.调度器：

• 持续时长。
• 启动延迟。

3.场景

测试计划。

线程组：30个线程，1秒，循环次数是永远，持续时间300秒。

15{__Random(1,9,)}{__Random(10000000,99999999,)}

输入用户参数。

消息体数据：引用变量mp。

聚合报告。

• 30个并发用户，持续运行300s。
• 聚合报告：avgRT：1.798s 90%RT：2.235s avgTPS：16.6
• 结论：
  • 90%RT：2.235s，可以看到，这个响应时间是比较长，已经超过了我们用户能容忍的范围了，用户满意度指数是1.5s，说明我们的接口响应比较慢。
  • 30个人，avgTPS：16.6，tps<user，那么每个人1秒钟发不了1个请求。所以，当前的这个时间里面，30个并发用户数，已经超过了我们项目这个接口能承受的最大并发用户数了。
  • 可以简单得到一个结论：服务器注册接口的最大并发用户数是小于30的。

这个是网络的吞吐率。

因为是局域网，图中这样的网络的吞吐率数据，肯定是没有网络瓶颈的。肯定不是网络问题，是服务器处理不了这么多的并发用户数。

响应时间图。

默认的情况下是10秒钟取一个点。

每个时间点的响应时间都不一样。

二、负载测试性能场景

「负载测试：」 逐步得增加并发用户数。看服务器的最大拐点区间在哪里。再缩小拐点区间，找出最大并发用户数。

• 插件：
  • 插件管理：安装这个插件jpgc。
  • 用5秒钟，增加10个并发用户数，持续运行30秒。

下载安装这个插件jpgc。

「线程组是用来设计性能场景的。」

从图片中可以看出：

每5秒钟增加10个并发用户数，这10个并发用户数持续运行30秒钟。30秒钟结束，然后再用5秒钟增加10个并发用户数，这20个并发用户数持续运行30秒钟。如此循环下去，总共增加100个并发用户数。

100个并发用户持续运行60秒钟，结束后，每1秒钟结束5个并发用户。

1.完全不知道项目的性能瓶颈范围时，我们怎么设置？

0~100，0~200，0~300，随便自己设置。

2.已经找到一个范围20-30了，怎么设置？

配置线程组。

随着并发用户数在增加，可以看到平均响应时间在缓慢的上升。

看平均线，不要看具体的某个点。

「每一段时间多少人，再找这段时间的响应时间。多张图一起来看，一起来分析。」

用户满意度指数是1.5s，可以看出注册接口的最大并发用户数是29。

三、脚本链接

https://gitee.com/qinghanstudy/gaojixingneng/tree/master/Advanced%20performance%20testing

文章中的图片，皆为小编本人所画所截图，计算机知识都一样，如有雷同，纯属巧合。「文章是清菡编写的，如有转载，请标明出处！」