2

我正在开发一个分布在两个 JBoss 实例上并在多个 JMS 队列上生成/使用 JMS 消息的应用程序。

当我们配置应用程序时，我们必须确定我们将使用哪种线程模型，特别是每个队列的生产和消费线程数。我们以一种相当临时的方式完成了这项工作，但是在阅读了 Herb Sutter 在 Dobbs 博士的最新专栏（特别是这个）之后，我想以更严格的方式调整我们的线程大小。

是否有任何方法/工具来测量 JMS 队列（特别是 JBoss 消息队列）的吞吐量作为生产/消费线程数量的函数？

4

2 回答 2

0

我为您准备了完美的东西：IBM 提供了一个名为 perfha​​rness 的免费命令行工具。

它旨在对 JMS 提供程序进行基准测试，即在给定不同数量的生产或消费线程的情况下测量队列（单个或多个）的吞吐量。

一些特点：

  • 以固定速率 (msg/s) 或队列上可能的最大速率发送和使用消息
  • 使用特定数量的线程
  • 使用 JMS 或本机 MQ
  • 可以使用随机生成的数据或从文件中获取的数据
  • 生成统计数据，准确告诉您队列的执行速度

唯一的缺点是它不是超级直观，因为它支持的操作数量。而且 IBM 还没有开源它，这是一种耻辱。但是，这听起来很适合您的目的。

于 2009-01-14T19:39:00.627 回答
0

这实际上与特定工具无关，但可能会有所帮助。

消费者：

不确定您的内部架构是什么，但让我们假设它是 MDB 读取消息。我断言，您对严格线程数大小的唯一要求是选择最大上限。如果您的 MDB 使用来自有限供应商（如 JDBC 连接池）的资源，请将最大上限视为您可以容忍使用的来自该资源的最大并发实例数。如果 MDB 的队列是远程的，您可能希望将远程连接（或技术上的 JMS 会话）视为有限资源。如果 MDB 的有限需求较少（并且队列是本地的），那么您的最大上限将变为线程数、使用的内存和/或工作线程消耗的 CPU 消耗量。这里的原因是 JBoss MDB 容器将简单地继续分配更多的 MDB 实例（以及因此线程），直到队列为空或达到最大上限。我能想到的唯一原因是，如果容器的运行时间或创建新实例的开销超出了您的容忍度，并且这些操作通常是非常小的土豆，那么您真的会为最小值感到痛苦。

生产者

消息传递的一般公理是生产者几乎总是胜过消费者。您可能会认为这是非常随意的，但这是我一直看到的一种模式，即使在广泛不同的消息传递场景中也是如此。无论如何，在不了解应用程序的情况下很难说线程应该如何为生产者工作，但是你基本上能够[无限地]按比例增加生产者线程的数量和生成的消息数量，或者你有一些额外线程根本不会产生更多消息的上限？我猜是后者，因为大多数有用的工作都有一些有限的数据或计算供应商。在我看来，这里的两个驱动因素是有序和坚持。

首先，如果您有严格的消息排序，其中消息必须以严格（FPFP）首先产生首先处理然后您处于一个绑定状态，因为您几乎必须下降到单线程吞吐量，除非您可以设计某种形式逻辑消息划分（例如，任何给定客户端的消息始终发送到同一个队列的客户端编号，但您可能有多个队列，每个队列由一个线程提供服务，因此每个客户端实际上都是 FPFP）。

撇开顺序不谈，持久性是下一个考虑因素，因为如果你有可靠和广泛的消息持久性，（或者对消息丢失有很高的容忍度），就让生产者线程去城里。消息将可靠地排队，最终消费者将 [希望] 赶上。但是，如果您的消息持久性消息计数或简单的队列深度可能会在它们变得过高时给您带来麻烦，那么这里可能会用到一个工具。如果您的生产者线程计数可以动态修改（它们可以在许多 Java ThreadPool 实现中），那么您可以对队列深度进行采样，并根据您定义的队列深度范围提高或降低生产者线程计数，可选到如果消费者基本上停滞不前，生产者也会停滞不前。我不知道执行此操作的特定工具，但在两个 JBoss 服务器之间，这很容易启动。选择你的队列深度——>生产者线程数会比较棘手。

说了这么多，我将实际阅读您链接到的文章.....

于 2009-01-06T12:00:57.100 回答