影响性能的消息服务因素

消息传送应用程序的性能不但受应用程序设计的影响，而且还受执行消息路由和传送的消息服务的影响。

以下各节讨论影响性能的各个消息服务因素。了解这些因素的影响对于评估消息服务以及诊断并解决在部署的应用程序中可能发生的性能瓶颈来说至关重要。

Message Queue 服务中影响性能的最重要的因素有：

• 硬件

• 操作系统

• Java 虚拟机 (Java Virtual Machine, JVM)

• 连接

• 代理限制和行为

• 消息服务体系结构

• 数据存储库性能

• 客户端运行时环境配置

以下各节讲述其中的每个因素对消息传送性能所产生的影响。

硬件

对于 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–2 传输协议速度

我们的测试比较了两种情况下的 TCP 和 SSL 吞吐量：一个高可靠性方案（将 1k 大小的持久性消息发送至长期订阅主题目的地，并使用 AUTO_ACKNOWLEDGE 确认模式）和一个高性能方案（将 1k 大小的非持久性消息发送至非长期订阅主题目的地，并使用 DUPS_OK_ACKNOWLEDGE 确认模式）。

总的说来，我们发现在高可靠性情况下协议具有较小影响。这可能是因为在高可靠性情况下所需的持久性开销在限制吞吐量方面是比协议速度更重要的因素。另外：

• TCP 提供与代理通信的最快方法。

• SSL 在收发消息时比 TCP 要慢 50% 到 70%（对于持久性消息是 50%，对于非持久性消息则接近 70%）。另外，SSL 在建立初始连接时比较慢（可能需要数秒钟），因为客户端和代理（在使用 HTTPS 的情况下则为 Web 服务器）需要建立私钥，以供加密要传输的数据时使用。性能的下降源自于加密和解密每个低级别 TCP 包时所需的额外处理。

• HTTP 比 TCP 或 SSL 都要慢。它使用 Servlet，该 Servlet 在 Web 服务器上作为客户端与代理之间的代理运行。封装 HTTP 请求中的包以及消息经过两个跃点（客户端到 Servlet，Servlet 到代理）后才到达代理的要求均涉及性能开销。

• HTTPS 比 HTTP 慢是因为需要额外的开销以加密客户端和 Servlet 之间以及 Servlet 和代理之间的包。

消息服务体系结构

Message Queue 消息服务可以作为单个代理实现，也可以作为多个互相连接的代理实例所组成的群集实现。

随着连接到代理的客户端数量以及所传送的消息数量的不断增加，代理最终将超出资源限制（例如文件描述符、线程和内存限制）。要适应不断增加的负载，方法之一是将更多的代理实例添加到 Message Queue 消息服务，从而将客户端连接以及消息路由和传送分布到多个代理。

通常，如果客户端（特别是消息生成方客户端）均匀地分布在群集中，则这种调整最为有效。由于在群集中的代理之间传送消息涉及到开销，因此对于连接数有限或消息传送速率有限的群集而言，其性能可能会比单个代理要低。

您也可以使用代理群集来优化网络带宽。例如，您可能希望在群集内的一组远程代理之间使用低速的长途网络链路，而在客户端与其各自的代理实例之间使用高速链接进行连接。

有关群集的详细信息，请参见第 9 章，使用代理群集。

代理限制和行为

代理可能需要处理的消息吞吐量是代理所支持的消息传送应用程序的使用模式的一个函数。但是，代理在以下资源上有限：内存、CPU 周期等。因此，代理可能会在无响应或不稳定的位置发生崩溃。

Message Queue 消息代理具有管理内存资源并防止代理用尽内存的内部机制。这些机制包括可以配置代理或其各自物理目的地可以拥有的消息数或消息字节数的限制，以及当达到物理目的地限制时可以实施的一组行为。

通过仔细的监视和调整，这些可配置机制可以用于平衡消息的内流和外流，使得不会发生系统过载。尽管这些机制会造成开销并限制消息的吞吐量，但它们可以维护操作的完整性。

数据存储库性能

Message Queue 既支持基于文件的持久性模块，也支持基于 JDBC 的持久性模块。基于文件的持久性使用单独的文件存储持久性数据。基于 JDBC 的持久性使用 Java 数据库连接 (Java Database Connectivity, JDBC™) 接口，并需要符合 JDBC 的数据存储库。基于文件的持久性通常比基于 JDBC 的持久性快；但是，某些用户对于符合 JDBC 的存储库所提供的冗余和管理控制更感兴趣。

如果是基于文件的持久性，您可以通过指定让持久性操作将内存中的状态与数据存储库同步，来最大限度地提高可靠性。这有助于消除因系统崩溃而导致的数据丢失，但代价是性能的下降。

客户端运行时环境配置

Message Queue 客户端运行时环境提供客户端应用程序及其与 Message Queue 消息服务的接口。它支持客户端向物理目的地发送消息以及接收来自这些目的地的消息所需的所有操作。客户端运行时环境是可配置的（通过设置连接工厂属性值），您可以控制其行为的各个方面（例如连接流度量、使用方流限制和连接流限制），从而提高性能和消息吞吐量。有关这些功能和用来配置这些功能的属性的详细信息，请参见客户端运行时环境消息流调整。