Java – Spring Websocket,RabbitMQ和STOMP的性能问题

我正在努力解决性能问题超过两个月,我无法解决它.因此,我想问一下问题可能是什么.

问题

我们使用Spring Websocket开发一个应用程序,其中客户端订阅其用户队列(/user/exchange/amq.direct/update)以接收它们的更新.我设置了JMeter测试,该测试订阅用户队列并每4秒发送一条消息,会话长度为12分钟.当运行大约300个线程(大约4500个请求/分钟结束)时,服务器的响应时间急剧增加到超过6秒(我认为在我的JMeter测试中超时).

测试在单独的机器上运行,应用程序在Linux(Debian)机器上运行,没有其他正在运行的应用程序.

我已经尝试过了什么

>使用内部消息代理(rabbitMQ)交换外部消息代理(rabbitMQ).有趣的是,对于内部代理,我可以处理多达2000个线程,但后来我进入相同的超时.
>我删除了每个业务逻辑,只发送一个简单的字符串作为STOMP消息
>我尝试了ClientInboundChannel和ClientOutboundChannel的不同配置
>我在WebSocketMessageBrokerConfigurer中尝试了不同的SendBufferSizeLimit
>为了验证我没有网络问题,我确实测量了来自ClientInboundChannel的传入消息的时间,直到它通过为它们实现ChannelInterceptors在ClientOutboundChannel中发送出去.这证实答案确实需要超过6秒才能发送出去.
>当websocket的响应时间变得非常糟糕时(哪个btw已经影响了新线程的STOMP连接调用),我对传统的http请求没有任何问题.
>我的航班记录显示CPU没有问题,并且在40％的峰值时,RAM也低于阈值,大约为1.5 GB.
>我也看不到线程争用或热门方法.
>我没有用完文件描述符.
>垃圾收集没问题.我在7分钟内只进行了4次运行,GC时间约为200-300 ms

由于我已经在这个话题上工作了很长一段时间,我可能已经忘记了很多我也尝试过的事情,所以请不要犹豫,开始谈话.

我希望你能给我更多灵感来寻找问题.

更新：

我发现我可以增加SimpleMessageBroker使用的DefaultSubscriptionRegistry的cachelimit.这导致只需使用该应用程序处理数千名用户.所以看起来这是RabbitMQ的一个问题.我用PerfTest工具测试了我们的RabbitMQ,并且在测试中我没有任何问题.但是测试也没有使用STOMP插件,而是使用amqp.

那么Spring Websocket中的外部消息代理有任何类似的限制吗？

更新2：

我能够使用示例应用程序重现该问题,您可以在github上找到它：
https://github.com/mld-ger/spring-websocket-performance-issue

此外,因为我认为这可能是春天的一个错误,我开了一张票：https://jira.spring.io/browse/SPR-16950

解决方法:

Flight Recorder仅记录由监视器争用(synchronized关键字)引起的延迟,这意味着其他延迟(例如由java.util.concurrent.*类引起)可能会被忽视.

争用也可能比Flight Recorder使用的默认20 ms阈值短.然而,这是不可能的,因为由于线程调度通常总是存在一些异常值.

如果不是由锁争用引起的,我的猜测就是它以某种方式与I / O相关.

标签：spring-websocket,java,performance,spring,rabbitmq
来源： https://codeday.me/bug/20190910/1800188.html