jmeter压测_Jmeter--Jmeter使用过程中的坑之WebSocket压测

题要：笔者之前几年前压测过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连接的主动关闭和被动关闭的，我理解客户端发送请求后，无法发起主动关闭，只能依靠响应的超时时间，达到超时后，才发起关闭……我之前二次开发的时候，遇到的问题也是这样的，没有主动关闭，只能依赖超时关闭）

截止此为止，问题很清楚了。