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

现在的问题是分布式压测比单机压测 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 降低正常，根本原因是客户机根本没有发起你预期的压力

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

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

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

搬个凳子看看

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

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

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

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 波动大的原因