|
| |
| Sun Java System Message Queue 3 2005Q4 管理指南 | |
第 11 章
分析和调整消息服务本章包括大量有关如何分析和调整 Message Queue 服务以优化消息传送应用程序性能的主题。本章包含以下主题：
关于性能本节提供有关性能调整的一些背景信息。
性能调整过程
消息传送应用程序的性能取决于该应用程序与 Message Queue 服务之间的交互。因此，要获得最佳性能，需要应用程序开发者和管理员的共同努力。
优化性能的过程从应用程序设计开始，一直持续到部署应用程序之后对消息服务的调整阶段。性能调整过程包括下列阶段：
上述过程常常需要反复进行。在应用程序的部署过程中，Message Queue 管理员应该评估消息服务器是否适用于应用程序的总体性能要求。如果基准测试程序测试符合这些要求，管理员就可以如本章所述调整系统。但是，如果基准检验测试不符合性能要求，则可能需要重新设计应用程序或者修改部署体系结构。
性能方面
通常，性能是对消息服务将消息从生成方传送到使用方时的速度和效率的一种衡量。但是，根据您的需要，可能会有几个不同的性能方面对您特别重要。
连接负载 系统所能支持的消息生成方、消息使用方或并行连接的数量。
消息吞吐量 每秒钟能通过消息传送系统抽取的消息数或消息字节数。
稳定性 消息服务的总体可用性，或者当负载较重或发生故障时性能的下降程度。
效率 消息的传送效率，这是一种与使用的计算资源相关的消息吞吐量的衡量。
这些不同的性能方面通常是相辅相成的。如果消息吞吐量很高，则意味着消息在消息服务器上作为待办事项累积的可能性就会变小，因此延迟时间也应该较低（单条消息可以很快地传送）。但是，等待时间可能取决于许多因素：通信链接的速度、消息服务器的处理速度和客户端的处理速度，以及其他许多方面。
在任何情况下，性能都有几个不同方面。哪些方面对您最重要？这通常取决于特定应用程序的要求。
基准测试程序
基准测试是为消息传送应用程序创建测试套件，并针对此测试套件衡量消息吞吐量或其他性能方面的一种过程。
例如，您可以创建这样一个测试套件：一定数量的生成方客户端使用一定数量的连接、会话和消息生成方，将标准大小的持久性或非持久性消息按照某个特定速率发送至队列或主题（这完全取决于消息传送应用程序的设计）。同样，测试套件中还包括一定数量的使用方客户端，它们使用一定数量的连接、会话和特定类型的消息使用方（通过特定的确认模式来使用测试套件的物理目标中的消息）。
使用标准的测试套件可以衡量消息的生成与使用之间所花的时间或者消息的平均吞吐速率，您还可以监视系统以观察连接线程使用情况、消息存储数据、消息流数据以及其他相关度量。这样就可以提高消息的生成速率、消息生成方的数量或者其他变量，直到性能受到负面影响为止。可能达到的最大吞吐量就是消息服务配置的基准。
使用此基准可以修改测试套件的某些特征。控制所有可能影响性能的因素时请小心（请参见影响性能的应用程序设计因素），您可以记录这些因素的更改如何影响基准。例如，您可以将连接数或消息大小增加五倍或十倍，并记录对性能产生的影响。
相反，您也可以将基于应用程序的因素保持不变，而以某种控制方式更改代理配置（例如，更改连接属性、线程池属性、JVM 内存限制、限制行为、基于文件与基于 JDBC 的持久性等），并记录这些更改如何影响性能。
当您需要通过调整消息服务来增加所部署的应用程序的性能时，这种应用程序基准检验可以提供非常有价值的信息。基准测试程序可用于更准确地预测所做的更改或一系列更改产生的影响。
通常，基准测试程序应该在受控制的测试环境下运行，并且运行足够长的时间，以使消息服务能够稳定。（性能在启动时会受到实时编译的负面影响，因为要将 Java 代码转换为机器代码。）
基线使用模式
部署并运行消息传送应用程序后，建立基线使用模式是很重要的。您需要知道何时发生峰值需求，并且需要能够量化该需求。例如，需求通常会随最终用户的数量、活动级别、一天当中的时间，或者以上所有这些因素而发生波动。
要建立基线使用模式，您需要在一段较长的时间内监视消息服务器，并查看如下数据：
还可以使用度量数据中提供的平均值和峰值。
将这些基线度量数据与设计时的期望值进行比较是非常重要的。通过执行此操作，可以检查客户端代码是否运行正常：例如，检查连接是否未保持打开或者已使用的消息是否仍然保留在未确认状态。这些编码错误会消耗消息服务器资源，并可能极大地影响性能。
基线使用模式有助于确定如何调整系统以优化性能。例如：
通常，您对使用模式了解得越多，就能越好地将系统调整为这些模式，并计划将来的需要。
影响性能的因素消息等待时间和消息吞吐量是两个主要的性能指示器，它们通常取决于典型消息在完成消息传送过程中的各个步骤时所需的时间。下列步骤显示了如何以持久、可靠的方式传送消息。这些步骤将在插图之后介绍。
图 11-1 通过 Message Queue 服务传送消息
因为这些步骤是连续的，所以任何步骤都可能成为消息从生成方客户端到使用方客户端的传送过程的瓶颈。这些步骤中的大多数都取决于消息传送系统的物理特征：网络带宽、计算机处理速度和消息服务器体系结构等等。但是，有一些步骤还取决于消息传送应用程序的特征和该应用程序要求的可靠性级别。
以下各节讨论应用程序设计因素和消息传送系统因素这二者对性能的影响。尽管应用程序设计和消息传送系统因素在消息传送过程中紧密交互，但它们彼此是独立的。
影响性能的应用程序设计因素
应用程序的设计决策对消息传送的总体性能有很大影响。
对性能影响最大的主要是那些影响消息传送的可靠性因素。其中包括下列因素：
其他影响性能的应用程序设计因素有：
接下来的几节讲述其中的每个因素对消息传送性能所产生的影响。通常，应当在性能与可靠性之间进行权衡。提高可靠性的因素可能会导致性能降低。
表 11-1 显示各个应用程序设计因素大体上如何影响消息传送性能。该表显示了两个方案（一个高可靠性、低性能方案和一个高性能、低可靠性方案）和分别对应于这两个方案的应用程序设计因素选项。在这两种极端情况之间，有很多可以同时影响可靠性和性能的选项和折衷。
注
在接下来的图中，性能数据是在一个使用基于文件的持久性的双 CPU、1002 Mhz Solaris 8 系统上生成的。性能测试首先预热 Message Queue 代理，使实时编译器可以优化系统，并使持久性数据库做好准备。
代理预热后，会创建单个生成方和单个使用方，并在 30 秒钟内生成消息。系统将记录使用方接收所有生成的消息所需的时间，并计算吞吐率（每秒收到的消息数）。对于表 11-1 中所示的不同应用程序设计因素组合，此情形会重复出现。
传送模式（持久性/非持久性消息）
持久性消息能够在消息服务器发生故障的情况下保证消息的传送。代理会将消息存储在持久性存储中，直到所有预期的使用方都确认已使用消息为止。
代理处理持久性消息比处理非持久性消息要慢，原因如下：
持久性和非持久性模式的性能之间可以有很大的差别。图 11-2 比较了在两种可靠的传送情况下持久性和非持久性消息的吞吐量：同时将 10k 大小的消息传送至队列和具有长期订阅的主题。两种情况下都使用 AUTO_ACKNOWLEDGE 确认模式。
图 11-2 传送模式的性能影响
使用事务
事务是一种保证，保证在一个事务会话中生成和使用的所有消息将作为一个单元进行处理或不进行处理（回滚）。
Message Queue 支持本地事务和分布式事务。
消息在事务会话中的生成或确认比在非事务会话中要慢，原因如下：
确认模式
确保可靠传送 JMS 消息的一种机制是，客户端确认使用了由 Message Queue 消息服务器传送给它的消息。
如果在客户端尚未确认消息之前就关闭了会话，或者如果消息服务器在处理确认之前发生了故障，代理将重新传送该消息，并设置一个 JMSRedelivered 标志。
对于非事务会话，客户端可以选择三种确认模式之一，这三种模式有其各自的性能特性：
（CLIENT_ACKNOWLEDGE 模式的用法与事务的用法类似，不同之处在于：它不能保证当提供者在处理过程中发生故障时，所有确认都将一起处理）。
确认模式影响性能的原因如下：
长期订阅与非长期订阅
主题目标的订户可以归为两类，即长期订阅的订户和非长期订阅的订户。
长期订阅的可靠性较高，但吞吐量较低，原因如下：
图 11-3 比较了两种情况下的长期订阅和非长期订阅主题目标的吞吐量：10K 大小的持久性和非持久性消息。两种情况下都使用 AUTO_ACKNOWLEDGE 确认模式。
从图 11-3 中可以看到，只有在持久性消息情况下，使用长期订阅的性能影响才会很明显，出现这种影响是因为持久性消息只有在长期订阅时才会永久存储，如上文所述。
图 11-3 订阅类型的性能影响
使用选择器（消息过滤）
应用程序的开发者常常需要将消息组的目标定为特定使用方。实现此任务的方法有两种：将每组消息分别指向一个唯一的物理目标；或者是仅使用单个物理目标，并为每个使用方注册一个或多个选择器。
选择器是一种只请求特定消息的字符串，这些消息的属性值应该与传送到特定使用方的字符串匹配。例如，选择器 NumberOfOrders >1 仅传送 NumberOfOrders 属性值为 2 或更大值的消息。
将使用方注册到选择器会降低性能（与使用多个物理目标相比），因为需要额外的处理来处理每个消息。如果使用选择器，则必须对它进行解析，以使它与将来的消息匹配。另外，路由每个消息时，都必须检索该消息的属性，并与选择器进行比较。但是，使用选择器为消息传送应用程序提供了更大的灵活性。
消息大小
消息大小会影响性能，因为从生成方客户端到代理以及从代理到使用方客户端之间必须传递更多的数据，并且对于持久性消息，必须存储更大的消息。
但是，通过将多个较小的消息组织成一个消息在一批中传送，对各个消息的路由和处理就可以变得尽可能地简单，从而获得总体性能的提高。此时，就会丢失有关各个消息的状态的信息。
图 11-4 比较了在两种情况下，1k、10k 和 100k 大小的消息的吞吐量（KB/秒）：持久性消息和非持久性消息。每种情况都将消息发送至队列目标，并使用 AUTO_ACKNOWLEDGE 确认模式。
图 11-4 显示在这两种情况下，传送较大消息的开销比传送较小消息的开销要小。您还可以看到在 1k 和 10k 大小的消息上出现的情况：非持久性消息较持久性消息接近 50% 的性能提高在 100k 大小的消息上并未得到体现，可能是因为在这种情况下，网络带宽已经成为消息吞吐量的瓶颈。
图 11-4 消息大小的性能影响
消息主体类型
JMS 支持五种消息主体类型，下面大致按复杂性顺序显示这些类型：
尽管通常情况下消息类型是由应用程序的需要所决定的，但较复杂的类型（MapMessage 和 ObjectMessage）会增加性能成本 - 对数据进行序列化和反序列化的成本。性能成本取决于数据的简单或复杂程度。
影响性能的消息服务因素
消息传送应用程序的性能不但受应用程序设计的影响，而且还受执行消息路由和传送的消息服务的影响。
以下各节讨论影响性能的各个消息服务因素。了解这些因素的影响对于评估消息服务以及诊断并解决在部署的应用程序中可能发生的性能瓶颈来说至关重要。
Message Queue 服务中影响性能的最重要的因素有：
以下各节讲述其中的每个因素对消息传送性能所产生的影响。
硬件
对于 Message Queue 消息服务器和客户端应用程序而言，CPU 处理速度和可用内存都是消息服务性能的主要决定因素。大多数软件限制都可以通过增加处理能力来消除，而添加内存则可以同时提高处理速度和容量。但是，仅通过升级硬件来克服瓶颈通常过于昂贵。
操作系统
由于不同操作系统的效率不同，因此即使硬件平台相同，性能也会各不相同。例如，操作系统使用的线程模型会对消息服务器可以支持的并行连接数产生重要影响。在所有硬件都相同的情况下，Solaris 通常比 Linux 快，而后者通常又比 Windows 快。
Java 虚拟机 (Java Virtual Machine, JVM)
消息服务器是受主机 JVM 支持并运行在其中的一种 Java 进程。因此，JVM 处理是决定消息服务器路由和传送消息的速度和效率的重要因素。
特别是 JVM 的内存资源管理至关重要。必须为 JVM 分配足够的内存以适应不断增大的内存负载。另外，JVM 将定期回收未使用的内存，而这种内存回收会延迟消息的处理。JVM 内存堆越大，内存回收过程中可能遇到的延迟就越长。
连接
客户端和代理之间的连接数和速度可能影响消息服务器可以处理的消息数以及消息的传送速度。
消息服务器连接限制
对消息服务器的所有访问都是通过连接进行的。对并行连接数的任何限制都会影响可以同时使用消息服务器的生成方或使用方客户端的数目。
与消息服务器的连接数通常受可用线程数的限制。可以对 Message Queue 进行配置以支持专用线程模型或共享线程模型（请参见线程池管理）。
专用线程模型的速度非常快，因为每个连接都有专用的线程，但是连接数目受可用线程数的限制（每个连接都有一个输入线程和一个输出线程）。共享线程模型对连接数不加任何限制，但是在大量连接之间共享线程会导致明显的开销和吞吐量延迟，特别是当这些连接都很繁忙时。
传输协议
Message Queue 软件允许客户端使用各种低级别的传输协议与消息服务器进行通信。Message Queue 支持连接服务中所述的连接服务（及相应协议）。
协议的选择基于应用程序的要求（加密、可通过防火墙访问等），但是所作的选择会影响总体性能。
图 11-5 传输协议速度
图 11-5 反映不同协议技术的性能特征：
消息服务器体系结构
Message Queue 消息服务器可以作为单个代理实现，也可以作为多个互相连接的代理实例（即代理群集）实现。
随着连接到代理的客户端数量以及所传送的消息数量的不断增加，代理最终将超出资源限制（例如文件描述符、线程和内存限制）。要适应不断增加的负载，方法之一是将更多的代理实例添加到 Message Queue 消息服务器，从而将客户端连接以及消息路由和传送分布到多个代理。
通常，如果客户端（特别是消息生成方客户端）均匀地分布在群集中，则这种调整最为有效。由于在群集中的代理之间传送消息涉及到开销，因此对于连接数有限或消息传送速率有限的群集而言，其性能可能会比单个代理要低。
您也可以使用代理群集来优化网络带宽。例如，您可能希望在群集内的一组远程代理之间使用低速的长途网络链路，而在客户端与其各自的代理实例之间使用高速链接进行连接。
有关群集的详细信息，请参见第 9 章“使用代理群集”。
代理限制和行为
消息服务器可能需要处理的消息吞吐量是消息服务器所支持的消息传送应用程序的使用模式的一个函数。但是，消息服务器在以下资源上有限：内存、CPU 周期等。因此，消息服务器可能会在无响应或不稳定的位置发生崩溃。
Message Queue 消息服务器具有管理内存资源并防止代理用尽内存的内部机制。这些机制包括可以配置代理或其各自物理目标可以拥有的消息数或消息字节数的限制，以及当达到物理目标限制时可以实施的一组行为。
通过仔细的监视和调整，这些可配置机制可以用于平衡消息的内流和外流，使得不会发生系统过载。尽管这些机制会造成开销并限制消息的吞吐量，但它们可以维护操作的完整性。
数据存储性能
Message Queue 既支持基于文件的持久性模块，也支持基于 JDBC 的持久性模块。基于文件的持久性使用单独的文件存储持久性数据。基于 JDBC 的持久性使用 Java 数据库连接 (Java Database Connectivity, JDBCTM) 接口，并需要符合 JDBC 的数据存储。基于文件的持久性通常比基于 JDBC 的持久性快；但是，某些用户对于符合 JDBC 的存储所提供的冗余和管理控制更感兴趣。
如果是基于文件的持久性，您可以通过指定让持久性操作将内存中的状态与数据存储同步，来最大限度地提高可靠性。这有助于消除因系统崩溃而导致的数据丢失，但代价是性能的下降。
客户端运行时配置
Message Queue 客户端运行时提供客户端应用程序及其与 Message Queue 消息服务的接口。它支持客户端向物理目标发送消息以及接收来自这些目标的消息所需的所有操作。客户端运行时是可配置的（通过设置连接工厂属性值），您可以控制其行为的各个方面（例如连接流度量、使用方流限制和连接流限制），从而提高性能和消息吞吐量。有关这些功能和用来配置这些功能的属性的详细信息，请参见客户端运行时消息流调整。
调整配置以提高性能系统调整
以下各节讲述您可以对操作系统、JVM 和通信协议所做的调整。
Solaris 调整：CPU 利用率、分页/交换/磁盘 I/O
有关对操作系统的调整，请参见系统文档。
Java 虚拟机调整
默认情况下，代理使用大小为 192MB 的 JVM 堆。这对于较大的消息负载来说通常太小，应该增大。
当代理快要耗尽 Java 对象使用的 JVM 堆空间时，它将使用各种技术（如流控制和消息交换）来释放内存。在极端情况下，代理甚至关闭客户端连接以释放内存并减少消息内流。所以最好将最大 JVM 堆空间设置得足够大，以避免这种情况。
但是，与系统的物理内存相比，如果最大 Java 堆空间设置过大，代理将继续增大 Java 堆空间，直至整个系统耗尽内存。这会导致性能的降低、不可预计的代理崩溃和/或影响系统中运行的其他应用程序和服务的行为。通常，需要有足够的物理内存以供操作系统和其他应用程序在计算机上运行。
总的说来，好的方法是：估算正常和峰值系统内存容量，并配置 Java 堆大小，使其足以提供良好性能，但同时不应过大，以免引起系统内存问题。
要更改代理的最小和最大堆大小，请在启动代理时使用 -vmargs 命令行选项。例如：
/usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"
此命令将启动 Java 堆大小设置为 256MB，将最大 Java 堆大小设置为 1GB。
- 在 Solaris 或 Linux 上，如果通过 /etc/rc*（即 /etc/init.d/imq）启动代理，请在 /etc/imq/imqbrokerd.conf (Solaris) 或 /etc/opt/sun/mq/imqbrokerd.conf (Linux) 文件中指定代理的命令行参数。有关更多信息，请参见该文件中的注释。
- 在 Windows 上，如果将代理作为 Window 服务启动，请使用 imqsvcadmin install 命令的 -vmargs 选项指定 JVM 参数。请参见第 13 章“命令行参考”中的服务管理器实用程序。
在任何情况下，都应当通过检查代理的日志文件或通过使用
imqcmd metrics bkr -m cxn 命令来验证设置。调整传输协议
选择了符合应用程序需要的协议后，基于该协议进行其他调整可能有助于提高性能。
可以使用下面三个代理属性修改协议的性能：
对于 TCP 和 SSL 协议，这些属性会影响客户端与代理之间的消息传送速度。对于 HTTP 和 HTTPS 协议，这些属性会影响 Message Queue 隧道 Servlet（在 Web 服务器上运行）与代理之间的消息传送速度。对于 HTTP/HTTPS 协议，还有其他可以影响性能的属性（请参见 HTTP/HTTPS 调整）。
协议调整属性将在以下各节中讲述。
nodelay
nodelay 属性影响给定协议的 Nagle 算法（TCP/IP 上的 TCP_NODELAY 套接字级选项的值）。Nagle 算法用于提高使用慢速连接（例如广域网 (Wide-Area Network, WAN)）的系统上的 TCP 性能。
如果使用了此算法，TCP 将通过把多个数据捆绑为较大的包来尝试防止将多个小块数据发送到远程系统。如果写入套接字中的数据没有填满需要的缓冲区大小，协议将延迟发送包，直到缓冲区被填满，或者经过了特定的延迟时间为止。填满了缓冲区或者发生了超时后，包将被发送。
对于大多数消息传送应用程序，如果包发送过程中没有延迟（Nagle 算法未启用），则性能是最佳的。这是因为客户端与代理之间的大多数交互都是请求/响应交互：客户端向代理发送数据包，并等待响应。例如，典型的交互包括：
对于这些交互，大多数包都比缓冲区大小要小。这意味着如果使用 Nagle 算法，代理会在向使用方发送响应之前延迟几毫秒。
但是，在连接较慢以及不需要代理响应的情况下，Nagle 算法可以提高性能。例如，客户端发送非持久性消息或者客户端确认未被代理确认（DUPS_OK_ACKNOWLEDGE 会话）就属于这样的情况。
inbufsz/outbufsz
inbufsz 属性用于在读取来自套接字的数据的输入流上设置缓冲区大小。同样，outbufsz 用于设置代理用来将数据写入套接字的输出流的缓冲区大小。
通常，这两个参数都应该设置为比收发的平均包稍大的值。一个很好的经验是将这些属性值设为平均包的大小再加上 1k（舍入为最接近的 k 倍值）。
例如，如果代理正在接收主体大小为 1k 的包，则该包的总体大小（消息主体 + 标题 + 属性）约为 1200 字节。大小为 2k（2048 字节）的 inbufsz 可以提供合理的性能。
增大 inbufsz 或 outbufsz（使其大于该值）可以稍微提高性能，但这样会增加每个连接所需的内存。
图 11-7 显示了对大小为 1K 的包更改 inbufsz 值的结果。
图 11-7 对大小为 1K（1024 字节）的包更改 inbufsz 值的结果
图 11-8 显示了对大小为 1K 的包更改 outbufsz 值的结果。
图 11-8 对大小为 1K（1024 字节）的包更改 outbufsz 值的结果
HTTP/HTTPS 调整
除了前面两节讨论的一般属性之外，HTTP/HTTPS 的性能还受到客户端向作为 Message Queue 隧道 Servlet 宿主的 Web 服务器发出 HTTP 请求的速度的限制。
Web 服务器可能需要优化，以处理单个套接字上的多个请求。在 JDK 1.4 版及更高版本中，与 Web 服务器的 HTTP 连接会一直保持（与 Web 服务器的套接字保持打开），以尽量减少 Web 服务器在处理多个 HTTP 请求时使用的资源。如果使用 JDK 1.4 版的客户端应用程序的性能比运行早期 JDK 版本的同一应用程序要低，则可能需要调整 Web 服务器的 keep-alive 配置参数以提高性能。
除了这样的 Web 服务器调整之外，您还可以调整客户端轮询 Web 服务器的频率。HTTP 是一种基于请求的协议。这意味着使用基于 HTTP 的协议的客户端需要定期检查 Web 服务器，以查看是否有消息在等待。imq.httpjms.http.pullPeriod 代理属性（以及相应的 imq.httpsjms.https.pullPeriod 属性）指定 Message Queue 客户端运行时轮询 Web 服务器的频率。
如果 pullPeriod 值为 -1（默认值），客户端运行时将在前一个请求返回后立即轮询服务器，从而最大限度地提高各个客户端的性能。结果，每个客户端连接都会在 Web 服务器中独占一个请求线程，这样可能会耗费 Web 服务器资源。
如果 pullPeriod 值为正数，客户端运行时将定期向 Web 服务器发送请求，以查看是否有挂起的数据。在这种情况下，客户端不会独占 Web 服务器中的请求线程。因此，如果有大量客户端在使用 Web 服务器，您可以通过将 pullPeriod 设为正值来节省 Web 服务器资源。
调整基于文件的持久性存储
有关调整基于文件的持久性存储的信息，请参见持久性服务。
代理调整
以下各节介绍为了提高性能可以对代理属性进行的调整。
内存管理：提高代理在负载下的稳定性
内存管理可以分别在各个目标上配置，也可以在系统范围级别内（对于所有目标）配置。
使用物理目标限制
有关物理目标限制的信息，请参见第 6 章“管理物理目标”。
使用系统范围的限制
如果消息生成方的数目超过消息使用方的数目，则消息可能在代理中堆积。代理包含限制生成方以及在内存很低的情况下将消息交换出活动内存的机制，但最好还是对代理可以保持的消息总数和消息字节总数进行严格限制。
可以通过设置 imq.system.max_count 和 imq.system.max_size 代理属性来控制这些限制。
例如：
imq.system.max_count=5000
上面定义的值表示代理最多只能保存 5000 条未传送/未确认的消息。如果发送了其他消息，它们将被代理拒绝。如果消息是持久性的，当生成方尝试发送该消息时，会收到一个异常。如果消息是非持久性的，代理将在不给出任何提示的情况下丢弃该消息。
如果在发送消息的过程中返回了异常，客户端应该暂停片刻，然后再次尝试发送。（请注意，异常绝不会是由于代理未能接收消息而引发的；所引发的异常都是由发送方客户端检测到的。）
多使用方队列性能
多队列使用方处理队列目标中的消息的效率取决于下列可配置的队列目标属性：
要达到最优的消息吞吐量，必须有足够数量的活动使用方以适应队列的消息生成方的速率，并且队列中的消息必须以最大化使用速率的方式路由和传送给活动使用方。Sun Java System Message Queue 技术概述中介绍了在多个使用方之间平衡消息传送的一般机制。
如果消息在队列中堆积，这可能是因为没有足够的活动使用方来处理消息负载。也可能是每批传送给使用方的消息太多，导致消息在使用方堆积。例如，如果每批的大小 (consumerFlowLimit) 太大，某个使用方就可能会收到一个队列中的所有消息，而其他活动使用方则一个也没有收到。如果使用方速度特别快，这也不会成为问题。
但是如果使用方相对较慢，而您又希望将消息均匀地分配给它们，则需要将每一批的大小减小。每一批的大小越小，将消息传送到使用方所需的开销就越多。但是，对于较慢的使用方，使用较小的批大小通常能获得网络性能的提升。
客户端运行时消息流调整
本节讨论影响性能的流控制行为（请参见客户端运行时配置）。这些行为可配置为连接工厂受管理对象的属性。有关设置连接工厂属性的信息，请参见第 8 章“管理受管理对象”。
消息流度量
客户端收发的消息（有效负荷消息）以及 Message Queue 控制消息通过同一客户端/代理连接传递。如果控制消息（例如代理确认）被有效负荷消息的传送阻挡，则控制消息的传送会发生延迟。为防止此类拥塞，Message Queue 会度量通过连接进行的有效负荷消息流。
有效负荷消息是成批的（由连接工厂属性 imqConnectionFlowCount 指定），以便只传送数目设定的一组消息。传送完一批后，将暂停有效负荷消息的传送，而只传送暂挂的控制消息。当另一批有效负荷消息传送后，接着又传送暂挂的控制消息，如此循环往复。
如果客户端执行的是需要代理作出大量响应的操作，则 imqConnectionFlowCount 应保持较低的值：例如，当客户端使用的是 CLIENT_ACKNOWLEDGE 或 AUTO_ACKNOWLEDGE 模式、持久性消息、事务或队列浏览器，或者正在添加或删除使用方时。从另一方面来说，如果客户端仅在使用 DUPS_OK_ACKNOWLEDGE 模式的连接上有简单的使用方，则可以增大 imqConnectionFlowCount 而不会降低性能。
消息流限制
在遇到本地资源（例如内存）限制之前，存在 Message Queue 客户端运行时可以处理的有效负荷消息数限制。如果达到了此限制，性能将受影响。因此，Message Queue 允许您限制每个使用方（或每个连接）能够通过连接传送和能够在客户端运行时中缓冲以等待使用的消息数。
使用方流限制
当传送到客户端运行时的有效负荷消息数超过任意使用方的 imqConsumerFlowLimit 值时，将停止传送该使用方的消息。仅当该使用方的未使用消息数下降至低于 imqConsumerFlowThreshold 设置的值时才会恢复消息传送。
下例说明了如何使用这些限制，以主题使用方的默认设置为例：
imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50
创建使用方后，代理将向此使用方传送第一批 1000 条消息（前提是有这么多），中间不会暂停。发送 1000 条消息后，代理将停止传送，除非客户端运行时要求更多消息。客户端运行将保存这些消息，直到应用程序处理它们为止。在要求代理发送下一批消息之前，客户端运行时会允许应用程序使用至少 50% (imqConsumerFlowThreshold) 的消息缓冲区容量（即 500 条消息）。
在同等情况下，如果阈值为 10%，则客户端运行时会等待应用程序使用至少 900 条消息，然后才会要求发送下一批消息。
下一批消息的大小按如下计算：
imqConsumerFlowLimit - (缓冲区中当前暂挂的消息数)
因此，如果 imqConsumerFlowThreshold 为 50%，则下一批的大小会在 500 和 1000 之间波动，这取决于应用程序处理消息的速度。
如果 imqConsumerFlowThreshold 设置得过高（接近 100%），代理就会发送较小的分批消息，这样会降低消息的吞吐量。如果该值设置过低（接近 0%），则客户端可以在代理传送下一组消息之前处理完剩余的缓冲消息，从而再次导致消息吞吐量下降。通常，除非您有特别的性能或可靠性考虑，否则不需要更改 imqConsumerFlowThreshold 属性的默认值。
基于使用方的流控制（特别是 imqConsumerFlowLimit）是管理客户端运行时中的内存的最好方法。通常，根据客户端应用程序的不同，您应该知道在任意连接上需要支持的使用方数、消息的大小以及可用于客户端运行时的内存总量。
连接流限制
但是在某些客户端应用程序中，使用方数量可能是不确定的，这取决于最终用户所作的选择。在这些情况下，您仍可以使用连接级流限制来管理内存。
连接级流控制可以限制针对一个连接上的所有使用方而缓冲的消息总数。如果该数目超过了 imqConnectionFlowLimit 的值，则通过该连接进行的消息传送将停止，直到消息总数降到连接限制以下为止。（只有当 imqConnectionFlowLimitEnabled 设置为 true 时，imqConnectionFlowLimit 属性才会启用。）
在会话中排队的消息数是使用该会话的消息使用方数量以及每个使用方的消息负载的函数。如果客户端在生成或使用消息时表现出延迟，您通常可以通过下列操作来提高性能：重新设计应用程序，以便在更大数量的会话之间分布消息生成方和使用方，或者在更大数量的连接之间分布会话。
