具有多个生产会话的单个JMS连接何时开始成为瓶颈？

Question

我最近阅读了很多关于JMS,Spring(和TIBCO EMS)关于连接,会话,消费者和生产者的最佳实践

在春天的世界里工作时,似乎流行的智慧

• 为消耗/传入流 -使用一个AbstractMessageListenerContainer与多个消费者/线程.
• 用于生成/发布流 - 使用CachingConnectionFactory下面的a JmsTemplate来维护与代理的单个连接,然后缓存会话和生成器.

对于生成/发布,这是我的(大型)服务器应用程序现在正在做的事情,之前它正在为它发布的每条消息创建一个新的连接/会话/生成器(坏!),因为使用了原始连接工厂JmsTemplate.旧的行为有时会导致在高峰时段在短时间内在代理上创建和关闭1,000个连接,甚至导致套接字/文件句柄限制.

但是,当切换到此模型时,我无法理解使用与代理的单个TCP连接的性能限制/注意事项.我知道JMS提供程序应该确保它可以以多线程方式使用 - 但从实际角度来看

• 它只是一个TCP连接
• JMS提供程序在某种程度上需要协调写入管道,因此它们不会导致交错混乱,即使它的内部协议中有一些分块
• 当然这涉及使用单一连接的线程/会话之间的一些争用
• 具有某些网络语义(代理的高延迟？不稳定的吞吐量？)肯定单个连接不理想？

假设我有点走上正轨

• 我是否偏离此基础并误解了底层连接如何工作并由JMS提供者共享？
• 任何争论都是通过建立更多连接来解决问题,还是只是将争用转移到经纪人？
• 有没有人有任何实际经验可以达到他们可以分享的限制？具有特定消息或网络吞吐量,或者甚至由并行共享连接的线程/会话数引起的
• 是否应关注单连接场景中关于写入非常大的消息阻止其他会话写入小消息的会话？

非常感谢任何想法或指向更多阅读主题或经验,即使与其他经纪人.

Answer 1

在考虑瓶颈时，请记住两个事实：

1. TCP 是一种流协议，几乎所有 JMS 提供商都使用基于 TCP 的协议

2. TIBCO EMS 客户端到 EMS 服务器的许多操作都是请求/回复的形式。例如，当您发布消息/确认接收消息/提交事务会话时，幕后发生的情况是，一些 TCP 数据包从客户端发出，服务器也会响应一些数据包。由于 TCP 流的性质，如果这些操作是从同一连接发起的，则必须将它们序列化 - 或者说，如果您从一个线程发布一条消息，并在同一时间从另一个线程提交一个会话，则数据包将在线路上混合，并且服务器无法从数据包中解释正确的消息。[注意：同步是从 EMS 客户端库级别完成的，因此用户可以随意与多个线程/会话/消费者/生产者共享一个连接]

我自己的经验是多个连接总是输出执行单个连接。在有损网络的情况下，使用多个连接绝对是必须的。在最佳网络条件下，通过多个连接，单个客户端几乎可以使客户端和服务器之间的网络带宽饱和。

也就是说，这实际上取决于您的客户的性能要求，良好网络下的单个连接已经可以提供足够好的性能。