题要:笔者之前几年前压测过WebSocket协议的请求,当时是自己二次开发引入Jar包进行的压测,由于水平问题,当时虽然实现了压测,但数据结果上存在瑕疵,统计有点问题。
而最近笔者又遇到了WebSocket协议的压测,发现最新的Jmeter5.0插件中有丰富的关于WebSocket的sampler,所以直接使用。
1、WebSocket Sampler使用---坑(请弃用)
界面很简单也很容易理解,这里不再赘述,我直接使用,单次调试脚本通过也通过了
但并发压测时却出现了问题,单并发亦是如此,我1个并发循环,RT高达8s以上……
一开始怀疑被测系统的问题,但后面经过开发大哥们的确认,以及我手动在系统上操作发现还是很快的,我手动点再怎么慢,也应该是1s以内的……
所以,排除了系统的问题,开始怀疑插件的原因。
2、WebSocket request-response Sampler (可用)
所以我开始寻求答案,心想实在不行估计又得折腾搞二次开发了,但仔细研究JMeter的插件时发现了下面还有一个插件……
眼前一亮,抱着试试的态度,调试脚本后,并发压测,发现一切正常,RT都在几十毫秒级……
总结:
1、JMeter压测WebSocket 协议时,建议直接使用WebSocket request-response Sampler插件,WebSocket Sampler我已经趟过坑了(个人怀疑可能是在socket连接的创建或释放机制上存在性能问题),就不建议使用了。
精力有限,也懒得去打开源码看到底是什么原因导致的了……当然有兴趣的同学也可以将这个sampler提个bug给开发组
2、此外,关于WebSocket抓包,建议使用谷歌浏览器F12或者fiddler之类的工具。Web端的使用F12就很方便的。(抓包这种基础操作不在此详述了,网络上也很多方法。如果有疑问的,可以在下面留言,人多的话,我可以再整理一篇手把手的教程。)
-------------------后续更新------------------------
3、关于WebSocket Sampler-Streaming Connection
经过我后面的排查,发现我在创建脚本时,勾选了Streaming Connection,关于配置的解释如下:
Streaming Connection –
选择这个TCP session要不要保持,如果勾上标识连接会一直存在;
如果没有勾上,那么得到第一次响应后该链接就会被关闭。
所以我在尝试不勾选的情况下,发现脚本是正常的;而在勾选的情况下,却发现脚本的响应时间异常,正如我上面猜测的一样,就是在连接上的问题(事实上,即便Tcp session 保持的话,应该也不影响我请求重服发送的,但实际上却影响到了,不知道是这个选项本身的问题还是和server端的配置有关系。有清楚这块的同学,也欢迎留言下,分享给大家下~)
本着求实的态度,我们来深入分析:
场景:1并发请求2次
A、不勾选Streaming Connection
B、勾选Streaming Connection
看到20s,我恍然大悟,这个数据和response的超时时间有关(默认最大20s)
改成100ms后,果然就回复了正常!
那么问题由来了,为什么WebSocket request-response Sampler压测没问题呢?
看下我们的配置
我们可以清楚的看到,我们的connection是新建的,相当于上面的不勾选Streaming Connection的场景,如果使用存在的connection,那么下面的超时时间肯定也要注意了(配置6s,也要等6s的间隔。)
-----------------------------最后再总结一次--------------------------
整个过程说白了还是和WebSocket的连接机制有关系:有点类似http的keep alive,但不完全一样。
1、每次新建连接,也就是不重用的条件下:前后两次的请求没有任何关系,互不影响;(压测时要注意连接数,因为每次都在创建)
2、重用连接(Streaming Connection)下:A1请求发出后,必须等待Session Closed:状态后,才会再次发送下一个A2请求(这里就涉及tcp连接的主动关闭和被动关闭的,我理解客户端发送请求后,无法发起主动关闭,只能依靠响应的超时时间,达到超时后,才发起关闭……我之前二次开发的时候,遇到的问题也是这样的,没有主动关闭,只能依赖超时关闭)
截止此为止,问题很清楚了。