5

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

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

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

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

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

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

假设我在正确的轨道上

  • 我是否在这里偏离了基础并误解了底层连接如何工作以及由 JMS 提供程序共享？
  • 任何争用是通过拥有更多连接来缓解的问题，还是只是将争用转移到代理？
  • 有没有人有任何达到他们可以分享的极限的实际经验？具有特定的消息或网络吞吐量，甚至是由并行共享连接的线程/会话数引起的
  • 在单连接场景中是否应该担心写入非常大消息的会话会阻塞其他写入小消息的会话？

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

4

2 回答 2

3

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

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

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

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

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

于 2014-09-18T06:34:24.067 回答
0

即使您使用一个连接和 100 个会话，这意味着您最终使用的是 100 个线程，这与使用 10 个连接* 10 个会话 = 100 个线程相同。

在达到系统资源限制之前你很好

于 2016-04-08T23:47:10.507 回答