activemq 性能测试_ActiveMQ性能测试

activemq 性能测试

我们使用ActiveMQ作为消息传递层–发送大量需要低延迟的消息。通常它可以正常工作，但是在某些情况下我们已经看到性能问题。在花了太多时间测试我们的基础结构之后，我想我已经学到了有关ActiveMQ的一些有趣的东西：它可能真的很慢。

尽管一般来说，消息通过ActiveMQ传输不会出现问题，但是我们注意到，当我们收到大量消息时，就会开始看到延迟。好像我们正在达到某个消息速率限制–当我们超过该消息速率限制时，消息将被延迟，仅在该限制处传递。从ActiveMQ贴上消息的时间戳起，我们可以看到代理正在快速接受消息，但是发送给使用者的时间有所延迟。

我设置了一个测试工具来复制问题，这很容易。但是，我在测试系统中测得的吞吐量似乎很低：每秒2500条消息。对于一个非常简单的消费者而言，基本上什么也不做，因此没有理由将吞吐量如此之低。为了进行比较，在完全相同的设置中使用定制的消息传递层，我们达到了每秒15,000条消息。第二个难题是在生产中，我们看到的消息速率仅为250消息/秒。为什么测试系统比生产系统快10倍？

我开始尝试消除可能性：

ActiveMQ上的并发负载没有区别
更改生产者流量控制设置没有影响
更改使用者的预取限制只会使行为变得更糟（我们将数据写入非持久性主题，因此默认的预取限制很高）
似乎没有组件受到带宽或CPU限制

作为实验，我尝试将使用者与代理人和生产者移动到同一台服务器上：消息吞吐量增加了一倍。将使用者移动到具有更高ping时间的服务器上：消息吞吐量骤降。

这导致了一个洞察力：ActiveMQ代理的行为恰好好像“一次”发送给消费者的数据量受到限制。我特别意识到，网络上未确认的数据量似乎受到限制。如果连线较长，则数据到达使用者的时间更长，而确认返回的时间也更长：因此，代理每秒发送的数据更少。

ActiveMQ

这种行为突出了我们的第一个错误。我们使用Spring Integration处理用户端的消息路由，在一年前对Spring进行了升级，我们在该版本中获得的更改之一是更改了消息驱动通道适配器确认JMS消息的方式。以前我们的消息是自动确认的，但是现在确认模式是“事务处理”的。这意味着我们必须在将确认发送给代理之前完成整个消息处理链。

这就解释了为什么生产系统（对消息有用的工作）具有比测试系统低得多的数据速率。不仅是消息必须经过1毫秒的ping时间，消费者还没有发送完确认消息，直到消费者完成了对消息的处理，这可能还要花费几毫秒的时间。

但是更糟糕的是，交易确认似乎完全阻止了用户预取数据！我们通过事务处理确认所看到的吞吐量是一次在线上一个未确认的消息。如果我们将消费者移到更远的地方，我们的吞吐量将直线下降。即，代理在收到之前的确认之前不会发送新消息。与其代替消费者从经纪人那里预取数百条消息并依次处理它们，而是经纪人耐心地一次发送一条消息！难怪我们的表现糟透了。

通过spring集成配置更改可以轻松解决此问题。在测试系统中，我们的消息吞吐量从2500消息/秒增加到10,000消息/秒。不错的进步。

但是我很好奇，我们仍然看到经纪人的行为，好像网上未确认数据的数量受到限制吗？因此，我将使用者移动到相距较远的服务器上进行测试。结果？是! 代理仍然限制网络上未确认的数据量。即使自动确认了消息，对于经纪人将不会看到确认而发送的数据量也有一个硬性上限。

帽子的大小呢？约64KB。是的，在2018年，我的消息传递层一次只能传输64KB的数据。当经纪人和消费者超级亲密时，这很好。但是，将消费者与代理之间的ping时间增加到10ms，我们的消息速率将下降到5,000消息/秒。在100毫秒的往返行程中，我们的消息速率为500消息/秒。

这种行为感觉就像应该控制预取限制：但是，我们看到的消息（不超过60条1kB消息）比预取限制所暗示的要少得多。到目前为止，我还没有找到有关“消费者窗口大小”是否存在的任何确认。也没有任何特别修改行为的方法。使用方上TCP套接字缓冲区大小的增加将传输中的数据量增加到大约80KB，但没有增加。

我很困惑，很多人使用ActiveMQ，并且肯定有人会注意到像这样的数据上限吗？但是，也许大多数人使用ActiveMQ时，消费者和经纪人之间的ping时间非常短，根本就不会注意到它？

但是，人们必须在全球分布式部署中使用ActiveMQ –为什么没人能看到这一点？