我正在从 ActiveMQ“Classic”5.15.4 迁移到 ActiveMQ Artemis 2.17.0，我观察到性能下降。我与 1 个生产者就一个主题和不同数量的消费者使用该主题进行了测试。我正在测量从创建消息到消费者接收消息之间的时间。
测试是在一个由 3 个节点组成的集群上完成的，这些节点都相互连接。每个代理都嵌入在一个 JBoss 中。我使用了一个由 3 个节点组成的集群，因为这是我们当前的生产设置。我正在挑战这种设置，因为我们的消费者和生产者很少（每次少于 50 个）并且我们正在使用消息分组，但我需要在只有 2 个节点处于活动/备用模式的设置上进行 POC。
生产者始终以同一个节点为目标，消费者随机连接到其他 2 个节点。
我们可以看到，在所有情况下，Artemis 都比 ActiveMQ Classic 稍慢。我想知道这是否是预期的结果。
【问题讨论】：
一般来说，ActiveMQ Artemis 明显快于 ActiveMQ “Classic”，因为它们之间存在显着的架构差异。简而言之，与 ActiveMQ“经典”相比，ActiveMQ Artemis 被设计为完全无阻塞，并且在规模上表现得非常好。
但是，在这种情况下，您不会大规模地测试代理。您正在测试一个生产者和“不同数量”的消费者。这肯定不是那种需要 3 个代理集群的生产用例。一个使用中等甚至最小硬件的代理几乎肯定就足够了。
即使您将客户端数量推到 50 左右，我仍然认为一个活动节点就足够了。如果您使用消息分组，您肯定只想使用一个活动节点。有关集群消息分组的重要详细信息，请参阅the documentation。
请记住，您必须根据每个代理的配置来比较“苹果与苹果”，这一点也很重要。这不一定是微不足道的，尤其是在处理集群时。您没有分享您的代理配置，因此我无法评论它们是否在功能上等效或至少在功能上尽可能接近。在某些用例中，一个代理可能比另一个代理表现更好的原因有很多。
在过去几年中，SoftwareMill 发布了针对持久、复制队列用例的流行消息代理的基准测试。上一次 ActiveMQ "Classic" 和 Artemis 测试是在 2017 年。这里是the results。此后 SoftwareMill 不再测试 ActiveMQ “Classic”。
【讨论】：
性能测试非常复杂，如果您不控制环境的所有方面（网络数据包调整、操作系统调整等），则很难确定一种消息传递产品是否胜过另一种。
此外，呼应 @Justin Bertram 的评论，即为相似的消息流特征配置两个产品需要这两个产品、消息流模式和客户端应用程序编码方面的专业知识。
最后，当涉及到分布式系统和产品时 - 通常您会在产品限制之前达到环境限制方式 - 诸如磁盘性能、网络性能或应用程序延迟之类的事情通常会限制性能结果。特别适用于 80% 的企业工作负载，这些工作量不是大规模的。
最佳建议 - 了解您预期的消息流模式和消息大小。对该场景进行性能测试，直到您知道何时需要扩展。
【讨论】：