内容


WebSphere Enterprise Service Bus 中的大型对象最佳实践和调优

设计模式和调优

简介

确保在大型对象系统处理方面获得最优性能是中间件软件用户面临的一个常见问题。通常,大于或等于 1M 的对象被认为是 “大型对象”,需要特别注意。本文旨在提供在 64 位生产环境中利用 WebSphere Enterprise Service Bus (ESB) V7 产品高效处理大型对象的一些必要信息和建议。

注意事项和影响因素

本节提供关于处理大型对象时的主要注意事项和影响因素的信息。

JVM 限制

64 位架构的主要优势在于内存管理和可访问性。增加的数据总线带宽实现了对 32 位架构上通常可用的 4GB 以上可寻址内存空间的支持。尽管 Java 堆的大小限制取决于操作系统,但 32 位 JVM 拥有 1.4GB 左右的限制并不少见。64 位架构提供的增加的内存支持减轻了对 Java 堆大小的约束,在大型对象上执行操作时,这种约束可能成为 32 位系统上的一个限制因素。

一般来说,应该总是使用 64 位 JVM 来服务大型对象。

内存中 BO 的大小

应该注意,内存中业务对象 (BO) 的大小可能比线路上可用的表示要大得多。可能的原因有几个,最主要的有特征编码差别、消息流通过系统时所做的修改、事务处理过程中用于支持错误处理和回滚的 BO 副本。

并发对象的数量

可实现的响应时间通常与正在处理的并发对象的数量成反比,尽管现代 SMP 硬件正在一定程度上帮助缓解这些限制。要从您的系统获得最好的响应时间,可以限制同时处理的消息数量。由于对 Java 堆可能施加的压力,这一点在处理大型数据对象时特别重要。

可以通过以下方法限制同时处理的消息数量:

  • 限制用于驱动工作负载的客户机的数量。
  • 调优适当的线程池以限制并发线程的数量。

网络

处理大消息时,网络带宽可能是一个限制因素。如果我们考虑一个简单的客户机-服务器模式,客户机正通过一个 1G LAN 发送一条大小可以忽略不计的请求消息并接收一个 50MB 响应,那么最大理论吞吐量可以计算如下:

带宽 (1000MB) / 消息大小 (400MB) = 2.5 条消息/秒

如果只有单个客户机线程,那么这相当于 400ms 的可实现响应时间。

实际上,由于较低层级(TCP/IP 等)的开销,无法在应用程序层实现网络接口卡 (NIC) 的名义传输速度。NIC 速度的 70% 的最大吞吐量比较常见。

通过多层配置(见图 1)处理消息时,中间层上的网络负载是客户机或服务提供者的两倍 — 其效果等同于上面定义的场景的可实现吞吐量的一半。

图 1. 多层配置
多层配置
多层配置

应用程序设计模式

本节提供几个设计模式,以提高大消息处理性能。

分解输入

输入消息分解技术旨在将一条大消息分解为多条小消息,以便逐个提交。

如果大消息主要是一些小业务对象的集合,那么解决方案是将这些小对象组合为一些小于 1MB 的组合对象。如果有些独立对象有临时依赖项或 “全有或全无” 要求,那么解决方案就会变得更加复杂。

声明检查模式

声明检查模式与一种技术相关,这种技术在中介只需要大消息的几个属性时用于减小内存中 BO 的大小。

  1. 从消息中分离数据负载。
  2. 提取必要属性到一个较小的 “控制” BO。
  3. 将较大的数据负载持久化到一个数据存储中,将 “声明检查” 存储为 “控制” BO 中的一个引用。
  4. 处理较小的 “控制” BO,这种 BO 的内存占用较小。
  5. 当解决方案再次需要大型负载时,使用 'claim check' 键检查数据存储中的大型负载。
  6. 从数据存储区删除大型负载。
  7. 合并 “控制” BO 和大型负载中的属性,同时考虑 “控制” BO 中发生变化的属性。

协同定位的服务

应该实现的最重要的解决方案架构是利用一个单独的 JVM(专用服务器)来处理大消息,尤其是当您正在运行一个由小消息负载(高吞吐量/低响应时间)和大消息负载组成的混合事务时。即使大消息仅仅偶尔出现但需要较长的响应时间,也应该采用这种技术。

在托管大量服务的系统上,如果有的服务处理大消息负载,有的服务处理小消息负载,那么处理大消息引发的 GC 和消息处理开销可能对其他服务的性能造成不利影响。

如果我们有两个示例服务:

  • ServiceA — 主要处理大消息负载
  • ServiceB — 主要处理小消息负载(高吞吐量/低响应时间)

确保 ServiceA 与 ServiceB 位于不同的 JVM 上有如下两个好处:

  • 处理 ServiceA 上的大消息的 GC 和消息处理开销不会大幅影响 ServiceB 的高吞吐量和低响应时间性能。
  • 可以独立调优单独的 JVMs,以便为预期的工作负载优化它们。

性能调优

本节提供关于几个调优选项的信息和建议,要获得最优性能,必须理解并正确配置这些选项。

JVM 调优

本节描述与 JVM 相关的调优事项。

什么是 Garbage Collection?

Garbage Collection (GC) 是 JVM 的一种内存管理形式。GC 的触发器通常是一个分配失败。分配失败是指,由于可用空间不足,无法将一个对象分配到 JVM 堆。GC 的目标是清理不再需要的对象的 JVM 堆,从而向此前分配失败的对象提供足够的空间。如果 GC 被触发,但对象仍然没有足够空间,那么 JVM Heap 耗尽。

分代 GC 策略非常适合创建很多短期存活的对象的应用程序,这种情况对于中间件解决方案很常见。JVM Heap 被分割为三个部分(Allocate Space、Survivor Space 和 Tenured Space),尽管这在几种情况下提供性能优化,但在处理大消息时,您需要注意 JVM Heap 是如何被利用的。由于 JVM Heap 的大小约束,这可能是 32 位 JVMs 上的一个限制因素,建议在这类架构上不要使用 Generation GC 策略来处理大消息。由于增加的内存支持,64 位 JVMs 上的情况与此不同。

增加 JVM Heap 的大小?

处理一些大消息,特别是使用并发线程运行时,可能会导致 JVM Heap 耗尽。增加 JVM Heap 的大小能够减轻大多数 JVM Heap 耗尽问题,但是,需要保持平衡,以免这种更改的副作用影响性能。

增加 JVM Heap 的大小来补偿 JVM Heap 耗尽将导致 GC 触发前能够分配更多对象。这样做的副作用是 GCs 之间的间隔时间增加,从而增加处理分配失败所需的时间。

当一个 GC 中的所有其他 JVM 线程被临时阻塞时,即如果您有一个通常需要 3 秒钟完成的 Global GC 和一个响应时间为 1 秒的 Service Level Agreement (SLA),那么如果一个 Global GC 在该事务中发生,则 1 秒的响应时间将被超过。

如果您在 32 位 JVM(不建议用于大型对象处理)上运行,那么您可以通过不使用分代垃圾收集来最大化可用于处理大 BO 的空间。这将导致一个 “扁平堆”,其中,整个堆空间(而不只是保育空间)都可用于临时对象分配。

有替代方法吗?

如果一个服务同时处理多个大消息,那么 JVM Heap 中的可用空间可能会迅速耗尽。限制 Web Container Threads 的数量允许管理员进一步控制同时处理的消息的数量。这有助于缓解 Heap 耗尽问题,而无需将 JVM Heap 的大小增加得过大。

另外,您可以使用单个客户机将消息驱动到 WebSphere ESB 中,从而确保一次只处理一条大消息。这将帮助减少内存耗用并提供最优响应时间。限制包含大消息的入站客户机请求、使其顺序进入 WebSphere ESB 可以通过 DataPower 设备这样的前端服务器实现。

下一节将详细介绍 WebSphere ESB Administrative Console 提供的参数和设置。

管理调优

本节描述可以应用到 Administrative Console 中的一些相关参数、调优注意事项、推荐方法和信息。

MDB ActivationSpec

有几种方法可以访问 MDB ActivationSpec 调优参数:

Resources > Resource Adapters > J2C Activation Specifications > ActivationSpec Name Resources > JMS > Activation Specifications > ActivationSpec Name

图 2. 激活规范
激活规范

处理大消息时需要考虑两个属性:

图 3. 激活规范属性
激活规范属性
激活规范属性

maxConcurrency — 这个属性控制可以从 JMS 队列同时交付到 MDB 线程的消息数量。

maxBatchSize — 这个属性确定在一个步骤中从消息传递层提取多少消息并将其交付给应用程序层。

线程池

下列线程池通常需要调优:

  • Default
  • ORB.thread.pool
  • WebContainer

这些线程池的最大大小可以在 Servers > Application Servers > Server Name > Thread Pools > Thread Pool Name 之下配置。

图 4. 线程池
线程池
线程池

JMS Connection Pool

可以通过几种方法从 Admin Console 访问 JMS Connection Factories 和 JMS Queue Connection Factories:

Resources > Resource Adapters > J2C Connection Factories > Factory Name

Resources > JMS > Connection Factories > Factory Name

Resources > JMS > Queue Connection Factories > Factory Name

图 5. 连接工厂
连接工厂
连接工厂

从连接工厂的管理面板打开 Additional Properties > Connection Pool Properties。您可以从这里控制最大连接数。

图 6. 连接工厂属性
连接工厂属性
连接工厂属性

结束语

在大型对象上执行操作时,Java 堆大小约束可能会成为 32 位系统上的一个限制因素,但 64 位架构上增加的内存支持缓解了这个问题。

增加 JVM Heap 大小能够缓解大部分 JVM Heap 耗尽问题,但是,需要保持平衡,以免这种更改的副作用影响性能。

  • 适当调优 JVM,平衡 GC 间隔和 GC 暂停时间。
  • 考虑旨在减小 JVM 上的压力的可用设计模式。
  • 使用专用服务器处理大消息。
  • 通过大消息服务器限制并发性或单线程请求。

相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=777742
ArticleTitle=WebSphere Enterprise Service Bus 中的大型对象最佳实践和调优
publish-date=12012011