性能常识 消息平台性能测试总结

高春琪 · 2022年11月11日 · 最后由 高春琪 回复于 2022年11月16日 · 7483 次阅读

背景

短信发送效率不足,在业务层面并发量高时出现短信积压发不出去,造成生产事故

测试目标

由于第三方短信网关吞吐量最多为每分钟 2500,消息平台发送短信接口 Tps 预期值达到 tps=40/s。

测试类型

本次性能测试主要采用以下测试类型:
1、压力测试:关注大业务量情况消息平台的长时间运行状态和消费能力。
2、稳定性测试:长时间运行(12 小时)模拟被测系统的测试负载。
3、负载测试:测试系统的最大承受能力。

测试执行情况

(一)原系统压测情况
1.测试脚本准备:
(1)线程组:设置线程数 40,开启调度器设置运行时间 600 秒=10 分钟。执行发送短信接口前通过正则表达式提取器获取 token 信息。
(2)增加常数吞吐量定时器:吞吐量样本量 5000/min。
2.查看执行结果:
(1)发送短信速度 2500 条/min,持续运行时间 7 分 42 秒。
(2)Redis 统计数据量平均为 600 条/min,共消费 30min;和预期值相差 1900 条/min。

(二)优化后压测情况
1.测试脚本准备:
(1)线程组:设置线程数 40,开启调度器设置运行时间 43200 秒=12 小时。执行发送短信接口前通过正则表达式提取器获取 token 信息。
(2)增加常数吞吐量定时器:吞吐量样本量 5000/min。
2.执行结果
(1)发送短信速度 2500 条/min,持续运行时间 12h。
(2)Redis 统计数据量平均为 2470 条/min,共消费 12h。和预期值相差 30 条/min(每分钟发送短信条数和 redis 统计条数差值发生在统计时间临界值,统计到下一分钟里)

(三)优化后负载测试:
1 .测试脚本准备:
(1)线程组:设置线程数 40,开启调度器设置运行时间 600 秒=10 分钟。执行发送短信接口前通过正则表达式提取器获取 token 信息。
(2)禁用常数吞吐量定时器
2.执行结果
(1)发送短信速度约 130000 条/min,运行时间 22s。
(2)Redis 统计数据量最大值为 7152 条/min。

分析和建议

经过优化后系统发送短息消费能力明显提升,满足预期值。

结论

两个问题

在测试过程中有两个问题请教大家
1.常数吞吐量定时器使用是否正确?
2.线程数的设置为多少才最合理,参考什么来设置数量?

共收到 8 条回复 时间 点赞
仅楼主可见

最大线程数应该由基准测试(单并发能达到的最大 TPS)的结果来定。

收藏一下,有空好好学习

这个短信是真实发出去了还是做了拦截呢

不是真实发送短信的,开发参照第三方平台做了 mock

徐汪成 回复

之前没了解到 “基准测试” 的概念,感谢指点

不声不响 回复

感谢您的耐心回复!

之前确实看到过 2/8 原则的文章,并没有落到实际应用中,感谢您的指点

对于你的提问,可能是我的描述让你产生了误解,1 和 2 中的【查看执行结果:(1)发送短信速度 2500 条/min,持续运行时间 7 分 42 秒】指的是发送请求速度(每一条请求代表发送一条短信)和运行时间。

业务逻辑中没有 redis 参与,文中提到的 redis 主要是用来统计每分钟的消费数量,方便开发和测试查看消费情况,没有考虑 redis 能力。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册