可以采取哪些步骤来优化tibco JMS以获得更高的性能？

Question

我们正在运行一个高吞吐量系统，该系统利用tibco-ems JMS在主服务器和客户端连接之间传递大量消息。我们做了一些统计，并确定JMS是导致大量延迟的原因。我们如何才能让tibco JMS更有性能？有没有什么资源可以对这个话题进行很好的讨论？

Answer 1

如果您不需要持久性，那么使用非持久性消息是一种选择。请注意，即使您确实需要持久性，有时使用非持久性消息也更好，并且在崩溃的情况下执行不同的恢复操作(如重新发送所有消息)

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

• 崩溃很少见(因为恢复需要时间)
• 您可以轻松检测到崩溃
• 您可以处理重复的消息(您可能无法确切知道在crash

之前传递了哪些消息

EMS还提供了一些持久的机制，但与传统的保证交付相比，防弹能力较弱。这些机制包括：

delivery.

• you可以使用预取机制，而不是可以使用“至少一次”或“至多一次”的“只有一次”消息传递。
• 可以使客户端在应用程序请求消息之前将消息提取到内存中。

Answer 2

EMS不应该成为瓶颈。我已经做了测试，我们的服务器上有大量的吞吐量。

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

你在做什么类型的场景。

Pub/sup还是请求回复？您是否有临时的队列堆积。临时队列过多可能会导致性能问题。(主要是因为你没有正确地关闭一些东西而导致它们挥之不去)

如果是的话，你会发布到一个有持久订阅者的主题吗？尝试将主题桥接到队列中，并从中读取。持久的订阅者也会导致性能上的小问题，因为它需要跟踪谁拥有所有消息的副本。

确保您的发送进程有一个会话，并且通过该会话有多个调用。不要为每个操作打开一个完整的会话。在可能的情况下重用。对消费者做同样的事情。

当你完成的时候一定要关闭。EMS不会把事情搞清楚。因此，如果你建立了一个连接，然后关闭你的应用程序，这个连接仍然存在，并且会吸收资源。

即使发生崩溃，也要检查您对丢失消息的容忍度。如果你正在做Client ack，并且你是否崩溃处理消息并不重要，那么切换到auto。另外，我相信如果你使用的是(TEMS - Tibco EMS for WCF)，那么会话确认就有问题。因此，一条消息仅当它对整个消息进行处理时，我们从客户端ACK切换到具有Dups ok的客户端，并且它工作得更好)