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

Question

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

在 Spring 世界中工作时，流行的智慧似乎是

对于 消费/流入流量 - 使用 AbstractMessageListenerContainer有许多消费者/线程。

对于 制作/发布流程 - 使用 CachingConnectionFactory在 JmsTemplate 下方维护与代理的单个连接，然后缓存 session 和生产者。

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

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

这只是一个 TCP 连接

JMS 提供者在某种程度上需要协调写下管道，这样它们就不会最终出现交错的困惑，即使它在其内部协议(protocol)中有一些分 block

当然，这涉及到使用单个连接

的线程/ session 之间的一些争用

具有一定的网络语义(代理的高延迟？不稳定的吞吐量？)单个连接肯定不是理想的吗？

假设我在正确的轨道上

我是否在这里偏离了基础并误解了底层连接如何工作以及由 JMS 提供程序共享？

任何争用是通过拥有更多连接来缓解的问题，还是只是将争用转移到代理？

有没有人有任何达到他们可以分享的极限的实际经验？具有特定的消息或网络吞吐量，甚至是由并行共享连接的线程/ session 数引起的

在单连接场景中是否应该担心写入非常大消息的 session 会阻塞其他写入小消息的 session ？

将不胜感激任何想法或指针，以了解更多关于该主题的阅读或与其他经纪人的经验。

Answer 1

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

TCP 是一种流协议(protocol)，几乎所有 JMS 提供程序都使用基于 TCP 的协议(protocol)

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

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

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