1

我们正在运行一个高吞吐量系统，该系统利用 tibco-ems JMS 将大量消息传入和传出我们的主服务器到我们的客户端连接。我们进行了一些统计并确定 JMS 是造成大量延迟的原因。我们如何使 tibco JMS 性能更高？是否有任何资源可以很好地讨论这个主题。

4

2 回答 2

3

如果您不需要持久性，则使用非持久性消息是一种选择。请注意，即使您确实需要持久性，有时最好使用非持久性消息，并且在发生崩溃时执行不同的恢复操作（例如重新发送所有消息）

这在以下情况下是相关的：

  • 崩溃很少见（因为恢复需要时间）
  • 您可以轻松检测到崩溃
  • 您可以处理重复的消息（您可能不确切知道崩溃前发送了哪些消息

EMS 还提供了一些持久的机制，但不如经典的保证交付那么防弹，包括：

  • 您可以使用“至少一次”或“最多一次”传递来代替“恰好一次”的消息传递。
  • 您可以使用预取机制，该机制会导致客户端在您的应用程序请求消息之前将消息提取到内存中。
于 2011-02-23T07:45:27.977 回答
0

EMS不应该是瓶颈。我已经完成了测试，我们的服务器上的吞吐量非常大。

您需要尝试确定瓶颈在哪里。是消息的生产者还是消费者的问题。消息是否堆积在队列中。

你在做什么类型的场景。

发布/支持或请求回复？你有临时队列堆积。太多的临时队列会导致性能问题。（主要是当他们因为你没有正确关闭某些东西而徘徊时）

如果是这样，您是否发布到具有持久订阅者的主题。尝试将主题连接到队列并从中读取。持久订阅者也会导致性能上的小问题，因为它需要跟踪谁拥有所有消息的副本。

确保您的发送过程有一个会话和通过该会话的多个调用。不要为每个操作打开一个完整的会话。尽可能重复使用。为消费者做同样的事情。

确保完成后关闭。EMS 并没有解决问题。因此，如果您建立连接并关闭您的应用程序，连接仍然存在并占用资源。

即使发生崩溃，也要检查您对丢失消息的容忍度。如果您正在执行客户端确认，并且如果您在处理消息时崩溃并不重要，那么切换到自动。此外，我相信如果您使用的是（TEMS - Tibco EMS for WCF），会话确认会出现问题。因此，一条消息仅在对整个消息进行处理时，我们从客户端 ACK 切换到具有 Dups ok 并且效果更好的消息）

于 2013-10-25T04:45:06.243 回答