WebSphere Commerce 是一个 J2EE 应用程序，它部署并运行于 Application Server 上。WebSphere Commerce 部署了标准的三层应用程序架构：
- HTTP 层 一般是使用 IBM HTTP Server (IHS) 实现的。IHS 运行 Application Server HTTP 插件。这个 HTTP 插件运行 Application Server 和 WebSphere Commerce 服务器集群的第二级负载均衡。它也运行网络边界的一个重要的缓存功能 —— 缓存静态内容 —— 如，图像。
- 应用程序层 是 Application Server 和 WebSphere Commerce 服务器集群。对于 WebSphere Commerce 网站，这里是 CPU 计算最密集的位置。
- 数据库层 在整个 WebSphere Commerce 性能评价中也发挥着重要的作用。对于 WebSphere Commerce 网站，数据库层的计算一般不是 CPU 密集型的，但是会有很高的磁盘 I/O。
另一个需要考虑的方面是工作负载的常规视图关注于系统的稳定状态特征。假设一个大型互联网零售商准备一个大型促销活动。在准备这个销售活动时，零售商会将内容从缓存清除，重新启动 WebSphere Comerce JVM，加载一个只包含活动期间有效的商品的销售目录，然后激活促销活动折扣和礼品。
促销活动包括通常所谓的 “意外顾客折扣”，这是一种为在活动开始后访问网站的首次在线购物者提供特殊折扣。大量的购物者会尝试登录零售商网站，以获得顾客折扣。结果，在促销活动开始时，零售系统会遇到一个巨大的访问峰值，这会给处于相对冷机状态的系统造成巨大的压力。
我们将介绍 WebSphere Commerce 的工作负载和支持网站最高性能的底层硬件基础架构的特征类型。我们将主要关注于应用层和数据库层。而简单的 HTTP 层则超出本文的范围。
图 2 显示的是一个典型 WebSphere Commerce 集群的逻辑视图。一个 WebSphere Commerce JVM 集群会从一个数据库实例查询数据，并将数据存储到该数据库实例中。虽然 WebSphere Commerce 是一个 Online Transaction Processing (OLTP) 应用程序，但是一般情况下 90％ 以上的数据库访问操作都是购物者浏览网站目录时产生的 “读” 操作。应用层的缓存在 WebSphere Commerce 部署中发挥着重要的作用。它能够减少数据库访问和数据库输入／输出（I/O）瓶颈。缓存的密集使用会对
WebSphere Commerce 应用层硬件基础架构的需求产生重要影响。
图 2. 一个典型 WebSphere Commerce 部署的逻辑视图
在检查每一个 WebSphere Commerce JVM 堆的内容时，您会发现 60％ 至 80％ 的堆是被一些长期存在（终身的）对象所占用的，而只有 20％ 至 40％ 的堆是由存在时间相对较短的对象占用，它们一般是在 JVM 内存空间中创建的。长期存在的对象主要是存储在 Application Server dynacache 的可缓存对象 —— JSP、JSP 页面片断、扩展 WebSphere Command Framework 类的命令和分布式图。
对于一个典型的 WebSphere Commerce 客户，缓存的大小约为 6 GB。对于另外一些客户，缓存的大小可能高达 20 GB。现在，大多数 WebSphere Commerce 部署都使用 32 位的 JVM。这种 JVM 的性能比 64 位 JVM 更高一些，但是在 JVM 堆的最大值上有限制。这个限制值（-Xmx 参数）在不同平台上会有所差别，但是一般为 2GB。这意味着大多数缓存都是存储在 JVM 外部。
为了帮助解决这个问题，dynacache 提供了一个 “磁盘卸载” 特性。当缓存大于 JVM 堆时，dynacache 磁盘卸载会将缓存内容写到一个磁盘文件中。在一个优化的网站上，这个磁盘卸载文件会完全存储在文件系统缓存中，它位于 RAM 之外。对于磁盘卸载文件无法完全存储在 RAM 的情况，WebSphere Commerce 需要执行大量的磁盘 I/O 操作。WebSphere Commerce 的应用层工作负载性能通常会因为 RAM 和磁盘的快速访问而得到提升。
所有 WebSphere Commerce 工作负载都有的一个重要性能是高度并行性。在重大促销活动期间，高访问量的 WebSphere Commerce 网站会经历高达 10,000 个购物者同时浏览和下订单。Application Server Web 窗口会使用一个线程池来处理这样大数量的并发请求。一般情况下，在高访问量的情况下，每一个 WebSphere Commerce JVM 都会同时运行 30 至 50 个 Web 容器线程。
除了 Web 容器线程，WebSphere Commerce 还有一个调度器和许多实用工具（如 dataload 和 stagingprop），它们是并行执行的。这些特性一般在每个 JVM 上会多使用 30 个额外线程。WebSphere Commerce 的性能会由于支持大量并发执行线程的硬件平台而得到显著提升。
在数据库中，WebSphere Commerce 工作负载的硬件需求与应用层稍有不同。WebSphere Commerce 支持 DB2 和 Oracle® 数据库。在规模适中和经过优化的网站上，数据库的 CPU 使用率不会超过 40％。然而，磁盘的 I/O 操作是非常高的。
图 3. NMON 输出显示的是一个典型 WebSphere Commerce 网站的 I/O 特征
图 3 显示了一个性能测试的示例 NMON 输出结果。在这个例子中，LPAR 运行着一个 DB2 实例。在测试中，25％ 的 WebSphere Commerce 缓存（应用层）每 20 分钟会失效一次。这是模拟由一个外部 Enterprise Information System (EIS) 更新 WebSphere Commerce 数据库的存货清单的真实情况。
您可以发现，I/O 速率（图 3 所示的黄线）在测试中一直保持高吞吐量。另一个需要注意的方面是，尽管 WebSphere Commerce 是一个 OLTP 应用程序，但是 I/O 活动主要是由读操作引起的（如图 3 的蓝线所示）。DB2 和 Oracle 数据库都提供了允许将数据表数据缓存在 RAM 中的缓冲区。
POWER7 的 WebSphere Commerce 性能
这一节将介绍在 WebSphere Commerce 性能实验室中，POWER7 硬件上实现的一些性能结果。我们将了解一下 POWER7 能够支持多高的动态负载，然后讨论 WebSphere Commerce JVM 在这个平台上的扩展特性。
“Black Friday Cold Start” 基准是在真实事件发生后设计的，其中一位零售商需要在开始一个重大促销活动之前完全重新启动他的网站，才能够执行维护和加载与活动相关的目录和促销产品。我们使用三个 P570 来运行 Web 层和应用层，使用一个 P780 来运行数据库层。购物者负载在 1 秒钟内从 0 增加到 9,000，并且能够保持 1 个小时不出现功能错误。
我们的测试结果如图 4 所示。尽管使用了冷缓存和出现极速负载攀升，我们还是在同时出现 9,000 个购物者的情况下实现了 1,026 订单/分钟的最大吞吐量。测试的响应时间良好，CPU 使用率很快稳定在 65％ 以下水平。
图 4. 执行 Black Friday Cold Start 基准测试 —— 最大吞吐量与虚拟并发购物者总数
图 5 显示了一个模拟全天 Black Friday 销售活动的可靠性测试结果。在这个例子中，我们执行了上述 Black Friday Cold Start 基准测试，并且维持整整一个小时的 1,000 订单/分钟订单处理速度，模拟了 Black Friday 开放时间秒杀情况。然后，我们将订单速度降低到约 500 订单/分钟，并且维持负载 5 个小时，模拟了一整天的 Black Friday 销售活动。
图 5. NMON 输出显示其中一个 P750 WebSphere Commerce 应用层 LPAR 在全天的 Black Friday 可靠性测试的 CPU 使用率情况
尽管测试中工作负载在一开始就极速攀升，而且较高的订单速度维护了 6 个多小时，但是您会发现应用层 CPU 使用率很快就保持稳定状态，并且在测试期间保持稳定在 30-35％ 的合理范围。这证明了 POWER7 很适合处理 WebSphere Commerce 工作负载和产品所提供的强大吞吐量和可靠性特征。
图 6 显示了一个 WebSphere Commerce 可扩展性调查结果。在这个例子中，我们创建了一个 POWER7 LPAR，并在它上面部署了一个 WebSphere Commerce JVM。我们为 LPAR 设置了不同的内核数。对于每一种可用内核数，我们会执行一个递增测试来确定最大可能吞吐量。我们给 LPAR 分配全内核值和微分区的半内核值。我们用不同的颜色区分全内核和半内核数据点，以分析与微分区相关的可能开销。
图 6. 扩展一个 POWER7 平台的单个 WebSphere Commerce JVM 特性
结果显示，每个 JVM 有高达 4.5 个内核的接近完美的可扩展性特性。结果还显示，当给一个 JVM 分配 2.5 个以上内核时，微分区开销很小。微分区为 WebSphere Commerce 部署提供了非常大的灵活性。
您可以将 WebSphere Commerce 部署所需要的全部额外环境整合为 —— 分段、性能、整合和一般质量保证 —— 一个或多个 POWER7 服务器的 LPAR。这些额外的环境不总是需要分配所有的内核。微分区是一个强大的特性，它允许您最大效率地利用处理器资源。
图 7 演示了在 POWER7 上运行 WebSphere Commerce 的另一个重要方面。POWER7 模型中每个插槽（常用的芯片名称）的内核数可以是 4、6 或 8 个。我们在测试中使用的 P750 模型使用了 6 个内核的插槽。您可以看到，每个 JVM 最多 6 个内核时，最大吞吐量是以接近线性的方式增长。然而，当每个 JVM 的内核数从 6 增加到 7 时，我们观察到吞吐量在下降。这是因为进程执行现在需要跨总线协调，以一半的芯片时钟频率进行处理。
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1104_genkin/1104_genkin.html