问答 关于 jmeter 性能测试的问题,求大佬们解答

我去炒饭 · 2022年10月27日 · 最后由 果冻 回复于 2023年01月30日 · 12223 次阅读

为何单机测试时的 tps 和吞吐量那么高,分布就不行,压测机的那几台电脑在同一个机房,走一个网段的
【分布式】
分布式配置

分布式测试结果
聚合报告

响应时间

tps

每秒点击率

服务器资源占用

grafana 结果

以上是分布式的设置和结果
【单机】
下面这个是单机并发 3000,运行 60 秒,同步定时器 3000

聚合报告

响应时间

TPS

每秒点击率

Grafana 结果

共收到 17 条回复 时间 点赞

请把请求的配置贴出来,还有压测思路说一下。

润安 回复

现在的问题是分布式压测比单机压测 tps 还低,因为开发一直觉得,单台那么大的情况下没问题,那就真没问题,分布式出来的问题,也不接受这个吞吐量
请求配置


调度机不参与压测吧,这个数据看起来没有收集到其他机器的数据……还是配合下机器的 TCP 监控定位下问题,按理吞吐差距不应该这么大

结合你截图里分布式压测时响应时间 95% 都是在 106ms(单机是 3000ms),说明你分布式执行时实际给到服务端的压力应该是比单机 4000 并发低了很多的,否则响应时间不可能低这么多。至于实际分布式压测时,服务端的 tps 到底是多少,建议以服务端监控软件(看你图里有 grafana)为准。

建议分享一下你的压测拓扑结构(特别是分布式时,每台压测机和被压测节点的网络链路,看会不会由于网络原因导致压力传递不到被压节点),以及你分布式运行的具体命令参数、通过什么命令采集并生成截图里这些统计数据的等更详细的信息。

另外,也可以参照这份官方的分布式压测文档自查一下:https://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html

这个 同步定时器 设置问题,现在你单机了线程数设置成 1000 了,你同步定时器还是 4000 ,超时时间 3000ms
这个就是设置就是需要有 4000 个模拟 user 才会请求一次,现在你达不到 4000,只能超时时才发送一次请求,所以你看见 tps、rt、请求总数如图,给服务器的压力减少了,rt 降低正常,根本原因是客户机根本没有发起你预期的压力

king 回复

分布式线程数 1000,同步定时器的用户数该设置多少呢

我去炒饭 回复

同步定时器的用户数应该少于等于你的线程数

king 回复

同步定时器在分布式使用时,针对的是所有压测机并发数还是单台的呢?之前有在分布式测时,没加同步定时器,直接在线程数那里设置 1000,吞吐量也没上去,结果也不如单台测试的,想请教请教~

搬个凳子看看

可以看看系统的 tcp 并发数量是否被限制,有些电脑上数量会被限制的很小

分布式压测,源码是将整个 HashTree 都推送到从机去执行的,然后结果又是汇总的。
看不出来具体哪个机器的性能如何,可能 jmeter 认为测试的机器默认配置都一样

线程数 750*4 是怎么实现的?

YHC 回复

4 台负载机 750*4

1 个请求:
单机情况下:
并发:3000,持续运行 1 分钟,接口请求平均时间:238ms,发送请求:71707
循环:71707÷3000≈23.9 次,一次循环耗时 2.5s 左右

分布式情况下:4 台(假设分布式设置没有问题,4 台负载机压力均匀分布)
并发:750,持续运行 1 分钟,接口请求平均时间:155ms,发送请求:16906
循环:16906÷4÷750≈5.6 次,一次循环耗时 10.7s 左右

两者循环相差 8.2s,与同步定时器超时差 1.2s,考虑其他误差的话基本上问题就在同步定时器设置。但是如果分布式的同步定时器都设置成 750,就很难保证运行时做到 3000 并发,这个需要考虑下

不确定这种计算是否是正确的,可以试下

不论是单机还是分布式的结果 TPS 都非常不稳定,这个结果实际意义不大,还是分析一下 TPS 波动大的原因

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