本文探讨了在使用ActiveMQ作为消息中间件时遇到的性能问题。在高消息量场景下，发现ActiveMQ存在吞吐量限制和延迟现象。作者通过测试发现，网络延迟、确认模式（尤其是事务确认）以及预取限制是影响性能的关键因素。通过调整Spring Integration的配置，优化确认模式，可以显著提升消息处理速度。然而，即使自动确认，代理仍会限制网络上未确认数据的大小约为64KB，这在分布式部署中可能导致性能下降。
我们使用ActiveMQ作为消息传递层–发送大量需要低延迟的消息。 通常它可以正常工作，但是在某些情况下我们遇到了性能问题。 在花了太多时间测试我们的基础架构之后，我想我已经学到了有关ActiveMQ的一些有趣的东西：它可能真的很慢。
尽管一般来说，消息通过ActiveMQ传输不会出现问题，但是我们注意到，当我们收到大量消息时，就会开始看到延迟。 好像我们正在达到某个消息速率限制–当我们超过该消息速率限制时，消息将被延迟，仅在该限制处传递。 从ActiveMQ贴上消息的时间戳起，我们可以看到代理正在快速接受消息，但是发送给使用者的时间有所延迟。
我设置了一个测试工具来复制问题-这很容易。 但是，我在测试系统中测得的吞吐量似乎很低：每秒2500条消息。 对于一个非常简单的消费者而言，基本上什么也不做，因此没有理由将吞吐量如此之低。 为了进行比较，在完全相同的设置中使用定制的消息传递层，我们达到了每秒15,000条消息。 第二个难题是在生产中，我们看到的消息速率仅为250消息/秒。 为什么测试系统比生产系统快10倍？
我开始尝试消除可能性：
- ActiveMQ上的并发负载没有区别
- 更改生产者流量控制设置没有影响
- 更改使用者的预取限制只会使行为变得更糟（我们将数据写入非持久性主题，因此默认的预取限制很高）
- 似乎没有组件受到带宽或CPU限制
作为实验，我尝试将使用者与代理人和生产
最低0.47元/天 解锁文章
扫一扫
1778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
