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

Question

我最近阅读了很多关于JMS，Spring（和TIBCO EMS）关于连接，会话，消费者和安全的最佳实践。生产者

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

• 用于消费/传入流程 - 使用具有多个消费者/线程的AbstractMessageListenerContainer。
• 用于生成/发布流程 - 使用CachingConnectionFactory下的JmsTemplate来维护与代理的单一连接，然后缓存会话和生产者。

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

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

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

假设我有点走上正轨

• 我是否离开这里并且误解了底层连接如何工作并由JMS提供商共享？
• 是否有任何争用是通过建立更多连接来缓解问题，还是只是将争用转移到代理？
• 有没有人有任何实际经验可以达到他们可以分享的限制？具有特定消息或网络吞吐量，或者甚至由并行共享连接的线程/会话数引起的
• 是否应关注单连接方案中有关写入非常大的邮件阻止其他会话写入小邮件的会话？

非常感谢任何有关该主题或更多阅读经验的想法或指示，即使与其他经纪人也是如此。

Answer 1

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

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

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

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

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

Answer 2

  

即使你使用一个连接和100个会话，它最终意味着你   正在使用100threads，它与使用10个连接* 10 sessions =相同   100threads。

     

在达到系统资源限制

之前，你很好