确保在大型对象系统处理方面获得最优性能是中间件软件用户面临的一个常见问题。通常，大于或等于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的大小。

　　从消息中分离数据负载。

　　提取必要属性到一个较小的“控制”BO。

　　将较大的数据负载持久化到一个数据存储中，将“声明检查”存储为“控制”BO中的一个引用。

　　处理较小的“控制”BO，这种 BO 的内存占用较小。

　　当解决方案再次需要大型负载时，使用’claim check’键检查数据存储中的大型负载。

　　从数据存储区删除大型负载。

　　合并“控制”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上的压力的可用设计模式。

　　使用专用服务器处理大消息。

　　通过大消息服务器限制并发性或单线程请求。