就是使用 jmeter 压测时,使用不同配置的电脑作为压力机,比如一台 4g100M 带宽,一台是 64G1000M 带宽,进行压力测试时两者的性能结果差距很大,并且在压测过程中去请求接口,接口的响应时间和各自压测的响应时间又对的上,比如 4g 的电脑压测单个接口响应时间是 10S,在压测过程中去请求接口,响应时间也差不多符合,以 64G 压测同样并发数同样线程去压测,响应时间是 4s,在压测过程中同样去请求接口,响应时间也差不多符合,为什么两个机器压测产生的结果和服务器的结果相似,但是为什么两个结果相差这么大呢,希望有人帮忙解答一下
看下压力机的资源监控
从结果看发压机存在性能瓶颈,压测时需要做下发压机的资源监控。
个人觉得,压力机带宽是不是受限导致,简单来说就是压不上去,你要看这 10 秒是怎么构成的,http 请求的几个阶段花了多少时间,你服务端应该有 dashboard 可以查看到真实的服务返回时间。
谜底不就在谜面上吗?带宽 & 内存
请教下大佬为啥用配置较低压测,实际接口返回也是那么久呢,不应该是用配置差的压力机压测,用户实际去访问的接口应该不会搜压力机配置的影响吗
两台机器的下行带宽都满了,很奇怪你是什么业务需要这么大带宽?
并发数小的情况下,理论确实如此,但是你这个并发数好像已经很大了,已经达到压力机的性能边界。压力机成为瓶颈的话可以考虑分布式方式压测。
这个我压的是 400 并发,压的接口是请求视频(一个接口是 3s 的视频),所以带宽占用比较大,这里我比较疑惑的是为什么两台电脑的实际结果相差这么大,因为 4g 接口响应时间是 8s,32g 接口响应时间是 4s
如果是下载任务,没必要做性能测试,按带宽和文件大小做出除法就算出来了
首先压力机的网络出现瓶颈了,客户端线程阻塞,我理解你们视频的请求接口是不是长链接,服务端链接数增长会导致接口请求响应延长。当然具体原因要结合你们业务逻辑来分析。
视频占内存太大了,你可以看看 jmeter 设置的内存大小
本次压测的接口不是长链接,返回状态码是 200 的,对了大佬,关于这种长链接的如何设计脚本压测呢,也是使用接口请求方式吗,如果是的话,如何判定是否达标的标准呢
一般网卡本身的连接速率有限制一般是 1G,从图上看你两台压测机带宽都已经占满了,要用并发数乘以视频的分片大小计算下需要的带宽
内存方面不知道你的业务是啥,内存占得这么多
建议分布式压测,资源达到限制时,jmeter 启用的一样的线程数,但是请求实际是排队发的没有一次发出去,排队时间越长,响应时间越长
我觉得带宽不同,是导致接口响应不一样的主要原因,你可以两个客户端各只请求一次看一下响应时间,接口响应应该也会有差距,但没这么大;然后这种带宽要求高的接口压测,我理解应该以跑满服务端带宽为目标,因为真实的用户场景下,是非常多的客户端,客户端的带宽是不会跑满的。要跑满服务端带宽,压力机带宽应该大于等于服务端带宽(这要求较高,当然楼上也说了可以估算出来的 )
我理解压测应该先找到各自客户机的最大 TPS,采用爬坡法逐步加压。
这里直接就是 400 并发。压力系统的主要矛盾已经从服务器的计算能力转移成为你的 2 台压力测试机器 (客户端) 的性能瓶颈了。
千兆网卡的传输速率为 1000Mbps,你这都快跑满了。感觉网络这块极大概率是客户端瓶颈。
回到主题,不要以客户端的资源为压测目标。最重要是主要矛盾,TPS。从 0 逐步加上去去看。
你可以把 Jmeter 在配置高的机器和差的机器配置 1 个双节点的集群去分摊网络流量。
这个问题说明没弄懂压测原理,很明显你的服务没监控,监控了就知道,你这个发起端只是限制了你发起端的。正常的访问没影响大概率说明你那点压力没影响