我正在开发一个分布在两个JBoss实例上并在多个JMS队列上生成/使用JMS消息的应用程序。
当我们配置应用程序时，我们必须确定我们将使用哪种线程模型，特别是每个队列生成和使用线程的数量。我们以一种相当特别的方式做到了这一点，但在阅读了Dobbs博士的Herb Sutter最新专栏（特别是this one）之后，我想以更严格的方式调整我们的话题。
是否有任何方法/工具可以测量JMS队列（特别是JBoss Messaging队列）的吞吐量，作为生产/消费线程数量的函数？
答案 0 :(得分：0)
这不是一个特定的工具，但可能会有所帮助。
<强>消费者：
不确定你的内部架构是什么，但我们假设它是消息中的MDB读取。我断言，严格的线程数大小的唯一要求是选择最大上限。如果您的MDB使用来自有限供应商（如JDBC连接池）的资源，请将最大上限视为该资源中您可以容忍的最大并发实例数。如果MDB的队列是远程的，您可能希望将远程连接（或技术上，JMS会话）视为有限资源。如果MDB具有较少的有限要求（并且队列是本地的），则最大上限将变为工作线程消耗的线程数，内存数和/或占用CPU数。这里的原因是JBoss MDB容器将继续分配更多的MDB实例（以及线程），直到队列为空或达到最大上限。我能想到的唯一原因是，如果容器的创建新实例的耗用时间或开销高于容差，那么你真的会为最小化而苦恼。这些操作通常都是非常小的土豆。
<强>生产者
消息传递的一般原则是生产者几乎总是胜过消费者。你会认为这是非常武断的，但它是我看到的一种模式，即使在广泛不同的消息传递场景中也是如此。无论如何，很难说在不知道应用程序的情况下线程如何对生产者起作用，但是你基本上能够[无限期地]按比例增加生产者线程的数量和生成的消息数量，或者你是否有一些其他线程根本不生成更多消息的上限？我猜它是后者，因为大多数有用的工作都有一些有限的数据或计算供应商。在我看来，这里的两个驱动因素是订购和持久性。
首先，如果你有严格的消息排序，其中必须严格处理消息（FPFP）First Produced First Processed然后你有点绑定，因为你几乎必须下降到单线程吞吐量，除非你能设计某种形式的逻辑消息划分（例如，客户端编号，其中任何给定客户端的消息总是发送到同一队列，但是您可以有多个队列，每个队列由一个线程服务，因此每个客户端实际上是FPFP）。
除此之外，持久性是下一个考虑因素，如果你有可靠和广泛的消息持久性（或者对消息丢失有很高的容忍度），那就让生产者线程进入城镇。消息将可靠地排队，最终消费者将[希望]赶上来。但是，如果您的消息持久性消息计数或简单的队列深度可能会在它们变得过高时为您提供帮助，那么这里的工具可能会变得有用。如果您的生产者线程计数可以动态修改（他们可以在许多Java ThreadPool实现中），那么您可以根据您定义的队列深度范围对队列深度进行采样并提高或降低生成器线程计数，可选地，如果消费者基本上是停滞不前，生产者也是如此。我不知道这样做的具体工具，但在两个JBoss服务器之间，这很简单。选择队列深度 - ＆gt;生成器线程计数将更加棘手。
说了这么多，我实际上会读到你链接的文章......
答案 1 :(得分：0)
我为您提供了完美的服务：IBM提供免费的command line tool called perfharness。
它的目标是对JMS提供程序进行基准测试，即在给定不同数量的生产或消费线程的情况下测量队列（单个或多个）的吞吐量。
一些功能：
唯一的缺点是，考虑到它支持的操作数量，它不是超级直观的。 IBM还没有开源，这是一种耻辱。然而，这听起来非常适合您的目的。