高性能JMS消息传递 [英] High Performance JMS Messaging

问题描述

我阅读了今年UberConf的幻灯片，其中一位发言人提出Spring JMS为您的消息队列系统增加了性能开销的论点，但我没有看到任何证据支持幻灯片。发言者还指出，点对点比传统的发布 - 订阅方法更快，因为每条消息只发送一次而不是广播给每个消费者。

I read slides from this year's UberConf and one of the speakers is making the argument that Spring JMS adds a performance overhead to your message queue system, however I don't see any evidence to support that in the slides. The speaker also makes the case that point-to-point is faster than the traditional "publish-subscribe" method because each message is sent only once instead of being broadcasted to every consumer.

我想知道是否有经验丰富的Java消息传递专家可以在这里权衡并澄清一些技术细节：

I'm wondering if any experienced Java messaging gurus can weigh-in here and clarify a few technicalities:

• 实际上是否存在使用Spring JMS而不仅仅是纯JMS导致的性能开销？如果是这样，它是如何以及在何处引入的？有什么方法吗？


• 有什么实际证据可以证明P2P比pub-sub模型更快，如果是这样的话，有什么时候你想要pub-sub over P2P（即为什么变慢？！？）？

• Is there actually a performance overhead incurred by using Spring JMS instead of just pure JMS? If so, how and where is it introduced? Is there any way around it?
• What actual evidence is there to support that P2P is faster than the pub-sub model, and if so, are there ever any cases when you would want to pub-sub over P2P (i.e. why go slower?!?)?

推荐答案

1）主要的，Spring JMS的开销是使用JmsTemplate来发送没有缓存机制的消息。基本上，JmsTemplate将为您发送的每条消息执行以下操作：

1) Primary, the overhead of Spring JMS is the use of JmsTemplate to send messages wihtout a caching mechanism underneath. Essentially, JmsTemplate will do the following for each message you send:

• 创建连接


• 创建会话


• 创建制作人


• 创建消息


• 发送消息


• 关闭会话


• 关闭连接

• Create Connection
• Create Session
• Create Producer
• Create Message
• Send Message
• Close Session
• Close connection

这可以与您重复使用的手动编写代码进行比较东西：

This of could be compared to manually written code where you reuse things:

• 创建连接


• 创建会话


• 创建制作人


• 创建消息


• 发送消息


• 创建消息


• 发送消息


• 创建消息


• 发送消息


• 关闭会话


• 关闭连接

• Create Connection
• Create Session
• Create Producer
• Create Message
• Send Message
• Create Message
• Send Message
• Create Message
• Send Message
• Close Session
• Close connection

由于连接，会话和生产者的创建需要客户端和JMS提供者之间的通信，当然，资源分配，它会为很多小消息创造相当大的开销。

Since the creation of connections, sessions and producers needs communication between your client and the JMS provider and, of course, resource allocation, it will create pretty large overhead for lots of small messages.

您可以通过缓存JMS资源轻松解决此问题。例如，使用弹簧 CachingConnectionFactory 或ActiveMQs PooledConnectionFactory （如果您使用的话） ActiveMQ，你用这个问题标记了）。

You can easily come around this by caching JMS resources. For instance use the spring CachingConnectionFactory or ActiveMQs PooledConnectionFactory (if you are using ActiveMQ, which you tagged this question with).

如果您在一个完整的JavaEE容器中运行，那么当您检索JNDI连接工厂时，池内/缓存通常是内置的并且是隐式的。

If you are running inside a full JavaEE container, pooling/caching is often built in and implicit when you retrieve your JNDI connection factory.

当使用spring Default Message Listening Container接收时，Spring中有一个薄层可能会增加很少的开销，但主要方面是你可以根据并发性等来调整性能。这篇文章解释得非常好。

When receving, using spring Default Message Listening Container, there is a thin layer in spring that might add little overhead, but the primary aspects is that you can tweak the performance in terms of concurrency etc. This article explains it very well.

2）

PubSub是一种使用模式，其中发布者不需要知道存在哪些订阅者。你不能简单地用p2p模仿它。并且，如果你想要从一个应用程序向另外十个应用程序发送相同的消息，我认为如果你想将相同的消息从一个应用程序发送到另外十个应用程序，那么pub-sub设置将比发送消息十次p2p更快。

PubSub is a pattern of usage, where the publisher does not need to know which subscribers that exists. You can't simply emulate that with p2p. And, without any proof at hand, I would argu that if you want to send an identical message from one application to ten other applications, a pub-sub setup would be faster than to send the message ten times p2p.

另一方面，如果你只有一个生产者和一个消费者，那么选择带有队列的P2P模式，因为它在某些方面更容易管理。 P2P（队列）允许负载平衡，其中pub / sub不那么容易。

On the other hand, if you only have one producer and one consumer, choose the P2P pattern with queues instead, since it's easier to manage in some aspects. P2P (queues) allows load balancing, which pub/sub does not (as easily).

ActiveMQ还有一个混合版本， VirtualDestinations - 这主要是负载平衡的主题。

ActiveMQ also has a hybride version, VirtualDestinations - which essentially is topics with load balancing.

实际的实现因不同的供应商而异，但主题和队列并没有根本的不同，应该表现得相似。您应该检查的是：

The actual implementation differs by different vendors, but topics and queues are not fundamentally different and should behave with similar performance. What you instead should check on is:

• 持久性？ （=慢）


• 消息选择器？ （=慢）


• 并发？


• 耐用用户？ （=慢）


• 请求/回复，与临时队列同步（=开销=较慢）


• 队列预取（=影响某些人的表现）方面）


• 缓存

• Persistence? (=slower)
• Message selectors? (=slower)
• Concurrency?
• Durable subscribers? (=slower)
• Request/reply, "synchronously" with temporary queues (= overhead = slower)
• Queue prefetching (=impacts performance in some aspects)
• Caching

这篇关于高性能JMS消息传递的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！