接口测试 请教各位大佬:单查询接口的性能测试案例/场景该怎么设计?

今晚打老虎 · 2021年02月04日 · 最后由 今晚打老虎 回复于 2021年02月19日 · 960 次阅读

一个查询接口,需求只说明了使用频率约为 50/s
期望得出其查询的性能瓶颈(响应时间和 TPS),但是在场景设计方面不太确定,特在此请教各位大大
铺底环境:表内数据 400w,此请求响应数据量 3w
我有考虑过 (成功率都是 100%)
1.30-100 以 10 个一组进行并发递增,查看其响应时间和 TPS 情况,得出 TPS 期望值为 25 并发-24,峰值/拐点为 35 并发-28,相应时间也是如此对应点(40 并发)
2.50 并发无限循环持续加压运行 10 分钟,目标 TPS 为 25,查看其相应时间的期望点

希望各位大佬帮忙看看场景是否合适及缺陷,还是否有其他的场景点及注意点,在加压和指标观察点处也有些不清晰

共收到 8 条回复 时间 点赞

自顶!!!
请教各位大佬 TPS/响应时间在设计用例时的相互关系

TPS 期望值为 25 并发-24,峰值/拐点为 35 并发-28

这一段没太看懂。你需求里这个接口的响应时间要求是多少,好像没提到?

得出其查询的性能瓶颈(响应时间和 TPS)

针对这类需求,个人的一般玩法是:不断加压(比如 50 并发持续 3 分钟,然后 100 并发 3 分钟,直到达到典型业务场景的 5-10 倍),直到看到 TPS 恒定,响应时间随着加压而对应增加的现象。见到这个现象说明已经达到系统瓶颈了。至于多大算是极限,取决于可接受的响应时间有多大。

另外,也会测试下增加节点带来的性能提升情况,因为实际线上业务很可能突然压力会增大很多,这个时候直接加节点是最有效最快速的手段。需要看看加节点是否能提升性能,进而确定线上如果突然有活动,是否可以直接加节点解决。如果加节点无法提升性能的,需要想办法优化或者找到其他的能应对压力增大的预案。

单接口的话就没有太多场景可以设置了吧,主要考虑接口的查询逻辑和要关注的性能点,服务器压力、数据库压力等等,然后接口是否有缓存,存储层查询是否有缓存等等,中间件层等等,接口参数化等等(例如单一接口是动态参数,考虑业务场景下的不同参数)等等等等

你这个 50/s 是每秒请求呀,不是服务处理能力。吞吐量控制器控制的是你的每秒的总响应数。
所以这里你有两个场景要考虑【50/s 是指的一个人 1s 内查询了 50 次还是很多人在 1s 内总共查询了 50 次请求】
如果是第一种,那这个 50 就是总 tps 呀,处理能力已经被你圈死了
如果是第二种,那你就要先计算平均并发数,然后再去测你的性能瓶颈

还有不要同时艾特我跟几位社区大佬,我不配。。。

性能测试一般来说分为多个阶段、跑基线、阶梯加压到预期目标、跑基线、跑浸泡(不一定算)等等,看你针对的场景。一般我们认为跑性能测试的目的是为了找系统资源的拐点,建议可以结合性能监控工具采集并绘制相关折线图,便于分析定位瓶颈。希望对您有帮助😊

多谢各位大佬的回复,不胜感激🙏

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