使用 POWER7 技术提升 WebSphere Commerce 网站效率

消费者购物方式的改变是零售行业公认的一个重大转变。IBM 商业价值研究院最新进行的关于 "符合更智能消费者需求" 的研究发现,购物者希望与零售商以一种关联密切且又及时的方式进行交互。IBM® WebSphere® Commerce 提供了一些开发和交付高质量的最佳网站的软件。零售商关心的是在消费者每周 7 天、每天 24 小时的全天候访问的情况下,其网站在线互动的可靠性和性能,这是由底层硬件基础架构支持的。本文将介绍 POWER7® 芯片的架构,对 Websphere Commerce 功能进行详细介绍,并阐述 POWER7 技术是如何提供关键优势来满足来更为智能的客户需求。

Boyd Dimmock, 杰出工程师,分页式行业 CTO, IBM

Boyd Dimmock 的照片Boyd Dimmock 是一位杰出工程师和分布式行业的 Systems and Technology Group (STG) 首席技术官。她分析全世界各种 STG 品牌,将系统价值确定为业务解决方案,包括分布式存储环境和网络商务与企业分析。她在开发和销售零售系统与应用程序软件方面有 37 年的经验。



Mikhail Genkin, 性能架构师,WebSphere Commerce, IBM

Mikhial Genkin 是 WebSphere Commerce 的性能架构师。他有 15 年的软件研发经验,对许多 IBM 产品都有贡献,包括WebSphere Commerce、WebSphere Process Server、WebSphere Integration Developer、Rational Application Developer 以及 Visual Age for Java-Enterprise Edition。



2011 年 7 月 18 日

简介

IBM 为该领域带来了一个解决方案,它经过精心的优化,可以在所有渠道上交付无缝的品牌化购物体验,包括每个渠道中的数字和物理触点。通过为购物体验的各个阶段交付丰富的、个性化的、与环境相关的内容,WebSphere Commerce V7 能够提高顾客忠诚度,增加购物车大小。软件基础架构是基于面向服务的架构(SOA),它是以 WebSphere Application Server(之前称为 Application Server)和 DB2® 作为底层解决方案组件实现的。

Application Server 和 DB2 的架构基础能够在 IBM POWER7 系统上交付优化的性能和可扩展性。这个解决方案是基于支持接近实时的快速数据访问和交互式信息使用的软件与硬件架构。客户访问商务平台的到了增强,这是因为,基于 Power 服务器无与伦比的性能,新的硬件解决方案最高能够降低近 50% 的查询时间。POWER7 为这种解决方案提供了独特的虚拟化、高级内存管理、超负载支持和世界级可用性支持。下面将详细介绍这些特征。

认识 POWER7 架构

这一节使用 P750 和 P780 系统作为示例来讨论 POWER7 芯片架构和功能。

POWER7 芯片和缓存的异质性

POWER7 芯片架构构建于性能领先的 POWER6® 之上延续了 IBM 的分化。POWER7 在每一个芯片或插槽上增加了处理器内核密度,改进了多线程支持,并且改进了内核内存带宽(下面介绍)。这种芯片设计能产生比 POWER6 还要高的性能。

多核和动态线程的可用性允许 POWER7 支持在 WebSphere Commerce 服务器应用程序上运行大量 Java 虚拟机(JVM)。POWER7 芯片最高支持 8 个处理器内核,每一个有 4 通道 SMT。这相当于在一个芯片或插槽上支持 32 个逻辑处理器。Power 750 Express 服务器支持 1 至 4 个插槽,最多支持 32 个内核,能够支持最高 128 个并发计算线程。

由于主内存和芯片级内存缓存之间的延迟差别,POWER7 设计了三种级别的芯片级缓存机制(见图 1)。这种芯片包括 32 MB 的芯片级 L3 缓存内存,这是在嵌入式 Dynamic Random Access Memory (DRAM) 中实现的,而不将片外 L3 缓存用于早期所有双核 Power 芯片中。POWER7 芯片在芯片上实现了两个双通道 DDR3 内存控制器,它在每个芯片上能够支持 100 GB/秒的稳定带宽。这在系统高缓存使用时具有很大的优势。

图 1. POWER7 芯片架构
POWER7 芯片架构

POWER7 虚拟化和并发线程支持

PowerVM 是在硬件上实现的,具有比主流的 Intel® 虚拟化平台更高的性能、更高的可扩展性和更高的资源使用率。PowerVM 提供根据工作负载需求动态调整系统资源的功能,这样每一个分区都能够获得所需的资源。逻辑分区(LPAR)允许您在同一个系统上运行多个操作系统实例而不会互相干扰。宏分区允许一个 LPAR 共享其他分区的处理器。PowerVM 提供的宏分区功能具有更大的规划网站部署灵活性。PowerVM 可以在不中断的情况下调整不同应用程序的 CPU 和内存使用,从而实现零售商根据不同业务需求扩展的灵活性。

POWER7 进行了技术突破,能够在相同规模的主机(具有相同数量的插槽或内核)上运行更大的应用程序负载。由于采用了新的 Simultaneous Multi-Thread (SMT) 技术,它支持更高的中央处理器(CPU)使用率,从而使零售商的硬件投入能够产生更大的价值。SMT 是一种处理器技术,它允许多个线程在各个周期中发出指令。SMT 允许所有线程实例同时竞争和共享处理器资源。POWER7 最新支持了 SMT4,它具有比其他解决方案更多的硬件支持,从而能够支持更多应用程序并发实例。SMT4 支持更多的线程,AIX 能够基于它对应用程序的理解而利用更多的线程。Application Server V7 也对 SMT4 的功能使用进行了优化,这样基于 Application Server V7 开发的应用程序不需要修改就能够利用 SMT4 的优势(例如,WebSphere Commerce V7)。

内存提升

这种 POWER7 解决方案的内存提升价值在于能够为软件提供更多的内存存储数据。主动内存扩展(Active Memory Expansion)是一种新的 POWER7 技术,它能够将有效内存最大容量提高到大于真实物理内存容量的水平。创新的内存内容压缩或解压缩使内存能够扩容 100%。这使应用程序分区能够执行更多的操作,或者使服务器能够用相同的物理内存运行更多的分区。使用主动内存扩展能够提高系统的使用率,增加系统的吞吐量。

POWER7 内存架构使用了较高的可靠性、可用性和可维护性,具有高性能和低功耗的内存。P750 和 P780 使用 1066 Dynamic Random Access Memory (DRAM) 总线速率(bus rate)技术。DRAM 接口是双端口的,支持两倍于 POWER6 的带宽。备用 DRAM 和可选择镜像能够提升内存的 RAS。

当在 Intel 平台上采用同等强大的配置时,我们可以创建更多客户可管理的镜像。电力解决方案也具有简化系统管理的优势。

平台的可用性和可维护性

故障停机时间可能会对业务持续性造成严重影响,而对于 Smarter Commerce 而言,商务平台失效会很快对零售商的收益产生重大影响。如果网站出现故障,那么销售额马上就下降。POWER7 提供了一种高度可靠的解决方案平台。这种解决方案的关键是选择了基于电源虚拟化的高可用性配置,它允许应用程序自动从故障机转移到备份机。

零售商还能够减少与维护、空间利用和功耗相关的运营成本。在中高端 POWER7 系统中,并发维护支持使持续应用程序可用性成为可能。并发维护支持允许我们在保持系统在线的情况下应用修复补丁。AIX 支持热内核补丁。这个功能能够帮助零售商的系统在任何时候都保持在线。

兼容性

一定要理解的是,Application Server V7.x 使用了 POWER7 处理器的新功能,所以迁移到这种应用程序环境比原先保留的已有应用程序的二进制版本更具优势。这是最适合 WebSphere Commerce 的环境。

然而,POWER7 也支持兼容模式,它允许原本运行在 POWER5® 或 POWER6 处理器上的应用程序不需要修改就能够运行在 POWER7 上。这意味着,这些应用程序的代码不需要修改或重新编译就能够运行在兼容模式上。这提供了一种平稳地将旧系统迁移到新平台的方法,从而减少迁移到新系统的成本。这种兼容性模式在需要保留遗留应用程序的情况下是非常重要的,因为有时候这个部署可能支持上千个应用程序。

此外,虽然使用早期处理器兼容模式的逻辑分区能够运行在 POWER7 服务器上,但是 POWER7 处理器不能够模拟 POWER6 或 POWER5处理器的所有特性。例如,如果逻辑分区的当前处理器兼容模式设定为 POWER5 模式,那么逻辑分区可能不支持特定类型的性能监控功能。


行业趋势

尽管现在处于不景气的经济时期,但是在线零售业仍然处于高速增长期。许多高业务量的 WebSphere Commerce 客户仍然预期未来两年(2011 和 2012)在订单数上会有很大(高达 20%)的复合增长。在线零售也变得更加复杂和更具针对性,开始更广泛利用促销和营销活动来吸引网上购物者。零售商正利用 WebSphere Commerce 的丰富特性集来实现这一目标。他们也将他们的 WebSphere Commerce 部署与各种外部系统整合,一般情况下,这些措施都实现了分钟级的报价和存货信息更新。

下面的数字反映了在线零售业的总体发展方向(数字来自真实的客户部署):

  • 在 2009 年,对于非常依赖线上销售的零售商而言,一个 WebSphere Commerce 网站支持的最高订单率为 850 订单/分钟。到 2012 年,这个数字将达到 1,100 订单/分钟。
  • 在 2009 年,最高的订单速度是在大约 9,000 购物者在网站上并发购物时创造的。
  • 在 2009 年,最大的 WebSphere Commerce 部署约为 100 个 JVM。在 2010 年,这个数字达到 150。到 2011 年,这个数字预计达到 196 个 JVM。
  • 在 2009 年,这个领域使用的最大 WebSphere Commerce 目录约为 7,000,000 SKU。在 2010 年,这个数字将超过 10,000,000 SKU。到 2011 年,这个数字预计将增长到 30,000,000 SKU 以上。
  • 在 2010 年,这个领域的最大 WebSphere Commerce 数据库接近 1 TB。

这个增长速度不仅能够促进 WebSphere Commerce 部署在整个行业的发展,这是体现在所需要的内核数和 Websphere Commerce JVM 数的增长上,也会带来新的性能问题:

  • JVM 数增加会带来运营成本的增加。
  • 促销和降低活动引起的负载增加。
  • 外部系统引起的 CPU、网络和磁盘 I/O 快速变化。

下面,我们将介绍典型的 WebSphere Commerce 工作负载,然后讨论 POWER7 特性是如何帮助解决诸多此类问题的。


认识 WebSphere Commerce 工作负载

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 部署的逻辑视图

在检查每一个 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 特征
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 基准测试 —— 最大吞吐量与虚拟并发购物者总数
执行 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 使用率情况
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 特性
扩展一个 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 时,我们观察到吞吐量在下降。这是因为进程执行现在需要跨总线协调,以一半的芯片时钟频率进行处理。

图 7. 跨越多个芯片插槽边界的影响
跨越多个芯片插槽边界的影响

警告与最佳实践

下面的问题能够帮助您获得最佳的基于 POWER7 的 WebSphere Commerce 部署体验:

  • 运行最新版 AIX。完整的 P7 模式至少需要 V6.1.5.1 版本。在 AIX 的早期版本中,只能使用 P6 兼容模式的性能,其中性能差距最大为 30%。我们推荐您使用最新版本的 AIX 操作系统(本文编写时最新版本为 7.1)。
  • 设置合适的 LPAR 以避免跨越多个芯片插槽边界。当规划部署时,首先要决定您的插槽数。要查询您的模型技术文档确定这个数量。它可能是 4、6 或 8 个内核。一旦您理解了插槽数,就要规划一个合适的 LPAR 数,使它们不可能跨越多个插槽边界。如果您使用动态 LPAR,那么一定要特别注意保证 LPAR 不会因为增加而跨越多个插槽边界。
  • 使用最佳内核/JVM 比率。在开始时使用 4 内核/JVM 是一个不错的选择。如果您使用微分区,那么至少要使用 2.5 内核/JVM。
  • 使用足够的 Web 容器和调度器线程以完全利用 SMT4。如果没有使用足够的线程来完全加载 POWER7 内核,那么 WebSphere Commerce 就无法完全利用可用的计算能力。WebSphere Commerce 工作负载能力可从并行计算获益。为了实现最优性能,您可能需要使用更多的线程,而不是一个 SMT2 系统。
  • 保证 VIOS 具有足够的 CPU、内存和网络带宽。VIOS 服务器资源不足可能会造成整个系统的瓶颈。当对 VIOS 划分微分区时一定要小心。

POWER7 高容量 WebSphere Commerce 部署提供了最佳的硬件平台。理解这些问题能够帮助您发挥 POWER7 的最大价值。


结束语

WebSphere Commerce 工作负载可从提供高并发性和快速访问大量 RAM 的处理器架构中获益。一些重要的 POWER7 特性,如 SMT4、32 MB L3 芯片内缓存和支持 100 GB/秒吞吐量的两个双通道 DDR3 内存控制器,是最完美的选择。相比,基于 Nehalem 架构的 Intel 芯片提供的硬件支持是并发执行线程的一半(相当于 SMT2 水平),通常是一个更小的芯片内 L3 缓存(取决于处理器模型),RAM 吞吐量明显降低。在原始性能方面,POWER7 是高容量 WebSphere Commerce 客户的最佳选择。

虽然使用 Intel 硬件来部署高性能 WebSphere Commerce 网站也可以,但是 POWER7 特性具有更重要的性能优势。此外,POWER7 PowerVM 动态将资源分配到 LPAR 的功能允许您在一台 POWER7 服务器上同时分配生产、性能和其他 QA 环境。PowerVM 能够快速地将资源从 QA 环境迁移到生产环境,有助于控制不可预见状况。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=733501
ArticleTitle=使用 POWER7 技术提升 WebSphere Commerce 网站效率
publish-date=07182011