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