看下压力机的资源监控

从结果看发压机存在性能瓶颈，压测时需要做下发压机的资源监控。

这个是我在两台发压机上进行并发时的资源监控，看下是否是发压机存在问题

个人觉得，压力机带宽是不是受限导致，简单来说就是压不上去，你要看这 10 秒是怎么构成的，http 请求的几个阶段花了多少时间，你服务端应该有 dashboard 可以查看到真实的服务返回时间。

谜底不就在谜面上吗？带宽 & 内存

请教下大佬为啥用配置较低压测，实际接口返回也是那么久呢，不应该是用配置差的压力机压测，用户实际去访问的接口应该不会搜压力机配置的影响吗

两台机器的下行带宽都满了，很奇怪你是什么业务需要这么大带宽？

并发数小的情况下，理论确实如此，但是你这个并发数好像已经很大了，已经达到压力机的性能边界。压力机成为瓶颈的话可以考虑分布式方式压测。

这个我压的是 400 并发，压的接口是请求视频（一个接口是 3s 的视频），所以带宽占用比较大，这里我比较疑惑的是为什么两台电脑的实际结果相差这么大，因为 4g 接口响应时间是 8s，32g 接口响应时间是 4s

如果是下载任务，没必要做性能测试，按带宽和文件大小做出除法就算出来了

首先压力机的网络出现瓶颈了，客户端线程阻塞，我理解你们视频的请求接口是不是长链接，服务端链接数增长会导致接口请求响应延长。当然具体原因要结合你们业务逻辑来分析。

1. delay 是 delay.tps 是 tps。这是两个指标。
2. 性能影响的因素不限于：CPU 占用率，CPU 核数（或者是核数 * 占用率的组合），网络带宽限制，不同指令集带来的差异，不同存储介质带来的差异，内存限制，内存 IO 限制等等。。。

视频占内存太大了，你可以看看 jmeter 设置的内存大小

本次压测的接口不是长链接，返回状态码是 200 的，对了大佬，关于这种长链接的如何设计脚本压测呢，也是使用接口请求方式吗，如果是的话，如何判定是否达标的标准呢

一般网卡本身的连接速率有限制一般是 1G，从图上看你两台压测机带宽都已经占满了，要用并发数乘以视频的分片大小计算下需要的带宽
内存方面不知道你的业务是啥，内存占得这么多

建议分布式压测，资源达到限制时，jmeter 启用的一样的线程数，但是请求实际是排队发的没有一次发出去，排队时间越长，响应时间越长

我觉得带宽不同，是导致接口响应不一样的主要原因，你可以两个客户端各只请求一次看一下响应时间，接口响应应该也会有差距，但没这么大；然后这种带宽要求高的接口压测，我理解应该以跑满服务端带宽为目标，因为真实的用户场景下，是非常多的客户端，客户端的带宽是不会跑满的。要跑满服务端带宽，压力机带宽应该大于等于服务端带宽（这要求较高，当然楼上也说了可以估算出来的 )

我理解压测应该先找到各自客户机的最大 TPS，采用爬坡法逐步加压。
这里直接就是 400 并发。压力系统的主要矛盾已经从服务器的计算能力转移成为你的 2 台压力测试机器 (客户端) 的性能瓶颈了。

千兆网卡的传输速率为 1000Mbps，你这都快跑满了。感觉网络这块极大概率是客户端瓶颈。

回到主题，不要以客户端的资源为压测目标。最重要是主要矛盾，TPS。从 0 逐步加上去去看。

你可以把 Jmeter 在配置高的机器和差的机器配置 1 个双节点的集群去分摊网络流量。

这个问题说明没弄懂压测原理，很明显你的服务没监控，监控了就知道，你这个发起端只是限制了你发起端的。正常的访问没影响大概率说明你那点压力没影响