内容


大型主机作为 WebSphere 客户中心数据服务器的测试分析

Comments

背景

领先的企业和行业分析家已经确定,以客户为中心的业务战略的关键要素是获得所有系统和渠道都可以使用的客户数据的单一版本。这种解决方案通常被称为客户数据集成 (CDI)。CDI 解决方案管理客户运营事务处理并维护单一运营客户视图,即客户数据的记录系统。CDI 解决方案通过业务服务(或 Web 服务)与现有运营系统集成,这使得应用程序可从相互共享完整的客户数据和业务过程中受益,从而提高它们的应用效率(例如,通过给高价值客户提供更好的服务或发现客户销售机会)。

WebSphere Customer Center 是领先 CDI 解决方案,并且已被 Gartner Group 等行业分析机构公认为软件行业的佼佼者。WebSphere Customer Center 在行业中处于领导地位的部分原因是该应用程序具有广泛的功能。

WebSphere Customer Center 包含多个组件,使其成为一个有效、智能的实时客户数据集成解决方案。知识层长期保存所有当前和历史的客户主数据。操作层包含维护知识层中的数据的业务服务。智能层通过操作服务进行访问,它添加业务规则和事务管理智能,以便对事务进行运营化处理。完整性层通过操作服务进行访问,它维护知识层的数据质量。性能层包含用于优化和增强事务性能的组件。集成层包含已发布的接口,使供应商组件能够与核心操作层业务服务进行集成。接口层负责使用多种接口方法将操作服务与外部应用程序进行集成。

一个完整的客户数据集成 (CDI) 解决方案必须包含上述所有组件,才能按照要求提供配置应用程序的重要功能性和灵活性。智能和完整性组件使 CDI 解决方案成为智能且有效的运营系统,它可以实时响应事件,并且它所包含的业务逻辑支持跨多个部门管理数据的操作服务。

由于 WebSphere Customer Center 不仅具有广泛而且独特的功能性和支持满足特定业务要求的配置的能力,因此它成为 CDI 市场公认的领先产品,同时它维护核心产品升级路径,并且能够在苛刻的事务负载环境下运行。

详细了解 IBM WebSphere Customer Center 软件的信息,请访问:  ibm.com/software/data/masterdata/launch.html

一直以来,IBM的大型主机数据库的高可靠性,高稳定性,高可扩展性和大吞吐量著称。IBM大型主机在中国的金融、制造等支柱行业都有广泛的应用。财富排行1000强的企业, 尤其是对IT要求较高的银行业, 绝大部分都在使用大型主机。技术的不断创新,IBM主机数据库全面支持SOA(面向服务的架构体系)的服务能力,灵活的支持其他平台的各类应用。

DB2 UDB for z/OS是首选平台,它能够满足客户最苛刻的要求,包括可用性、可伸缩性、工作负载整合、与工具和其他应用程序的集成以及灵活性。为帮助客户处理不断增加的数据量和复杂的查询,DB2 UDB for z/OS交付了增强功能。这些增强功能可用于全球百强公司的重要应用程序,也可用于中小型企业的账目和会计系统。

  • DB2和Parallel Sysplex提供了业内独有的最高可用性。着眼于前瞻性可用性方法,zSeries软硬件通过25年的发展,提供了这种可用性。
  • DB2和zSeries的架构是成熟的。在大型机上工作的DB2数据库管理员能够管理比其他平台多3~4倍的数据量。
  • DB2交付了对可用信息的快速、安全的访问。它可以进行伸缩并提供不间断的快速访问。它具有重要的、扩展的灾难恢复功能。同时,它与一个具有行业领先可用性的操作系统协同工作。
  • DB2 for z/OS以安全的、高度可用的方式管理许多并发用户对大量数据的访问。它的环境构建于开放标准之上。
  • DB2是专为随需应变商务而设计的。它完全能够应对非传统数据数字化以及由于审计和规章要求带来的不断增长的安全和控制挑战。
  • DB2、z/OS和System z平台之间的紧密关系在业内是独一无二的。它交付了世界级的性能、可伸缩性和可用性。这使得所有规模的公司受益,包括当今世界运行重要应用程序的顶尖公司。这种紧密的伙伴关系是IBM不断发展的战略目标,也是IBM与众不同的标志。

基于上述原因,客户选定了DB2 for z/OS作为WebSphere Customer Center的数据服务器,本文将详细描述我们在对使用IBM大型主机作为数据库服务器, 使用P系列小型机作为应用服务器的典型架构下,对WebSphere Customer Center的和主机数据库进行性能测试,并且论证IBM大型主机作为数据库服务器的先进性。

图 1. 典型架构
典型架构
典型架构

系统环境和验证方法

根据客户的测试要求,我们在IBM测试中心部署了一整套测试环境,物理架构如下图所示:

图 2. 物理架构
物理架构
物理架构

如图所示,本次测试使用了一个主机逻辑分区作为数据服务器,一个P690逻辑分区作为测试服务器,4个P690逻辑分区作为应用服务器。

WebSphere Customer Center应用服务器环境

本次测试使用了4个p690的逻辑分区, 每个逻辑分区4颗1.9GHz CPU,8GB内存。

测试服务器

本次测试使用了1个p690的逻辑分区,4颗1.9GHz CPU,8GB内存,用于运行测试程序。

性能验证方法

在性能验证架构中,性能验证模拟程序和WebSphere Customer Center应用服务器都通过WMQ连接。性能验证模拟程序将服务请求以XML格式的报文形式通过MQ和发送到WebSphere Customer Center应用服务器,WebSphere Customer Center应用服务器处理服务请求,并将结果通过MQ返回性能验证模拟程序。具体的消息流转如下图所示:

图 3. 消息流转示意图
消息流转示意图
消息流转示意图

主机数据库系统环境

硬件环境:

本次测试使用了z990(2084-B16)的一个逻辑分区, 4颗CP, 共约1418Mips。

z990于2003年5月推出,是IBM z9主机的上一代主机产品。在当时,它建立了企业级计算的新标准,拥有行业领先的虚拟、自动化、可扩展性、安全性和可靠性特性。这种IBM大型机从设计之初就考虑到如何阻止对系统的入侵,是当今市场上最安全的服务器之一。该产品的推出花费4年努力,投资超过10亿美元。

有关 z990的介绍可以参见: http://www.ibm.com/cn/systems/z/z990/

根据客户的实际环境要求,本次测试并没有使用当前最新的大型计算机硬件系统System z 9系列的产品。

软件环境:

根据客户的实际情况, 我们使用了:

  • z/OS Version1 Release 7操作系统:Z/OS 一个基于新的 Z 系列体系结构的新的、稳定的操作系统, 支持新的64位的计算环境,它代表了IBM 390主机操作系统的发展方向。
  • DB2 for z/OS Version 7关系型数据库系统:DB2 Universal Database Server for OS/390 and z/OS, 7 版本为电子商务和数据仓库应用提供了增强的性能、可用性、和可扩展性 。

根据客户的实际环境要求,本次测试并没有使用最新的操作系统和数据库版本,最新的系统z的操作系统版本为z/OS V1.8, 数据库系统为 DB2 for z/OS Version 9。

主机主要报告参数说明:

在测试中,我们跟踪了DB2 Class 1和Class 2作为主要测试参数。

数据库处理时间(CLASS1):指从数据库服务器端监控得到的从连接DB2开始到交易结束线程所用的总消耗时间。该时间包括在DB2外(应用和网络)消耗的时间。Class 1 time shows the time the application spent since connecting to DB2, including time spent outside DB2. 数据来源是DB2 Accounting Report。

数据库处理时间(CLASS2):指实际消耗在DB2内的时间,包括CPU时间和等待的时间。Class 2 elapsed time shows the time spent in DB2. It is divided into CPU time and waiting time. 数据来源是DB2 Accounting Report。

数据库服务器压力(%):指主机当时平均CPU使用百分率。数据来源: RMF Report。

测试案例

本次测试测试了两个WebSphere Customer Center的两个典型交易: 基本查询(Get Person)和增加客户(Add Person), 其中基本查询(Get Person)交易在实际客户需要中使用最为频繁, 约占交易总量的89%以上。而增加客户(Add Person)是相对复杂一些的交易, 在实际应用中, 平均使用率约占交易总量的3%左右;而在应用使用初期, 增加客户(Add Person)的使用可能更加频繁。

为模拟客户的实际需要, 我们分别测试了客户数量1000万和5000万这两种情况。模拟国内大型银行的客户数量增长的得实际情况。由于测试时间的限制, 在数据量增加的情况下, 并没有重新规划数据库结构。仅仅使用DB2 for z/OS最基本的Segment Table。

测试结果与分析

本次测试结果如下表所示,

案例结果分析

下面的分析基于表一的基础数据,

1.  数据库处理时间(CLASS1)远大于数据库处理时间(CLASS2)

图 5. 数据库处理时间
数据库处理时间
数据库处理时间

对于基本查询(Get Person)交易,处理时间(CLASS1)约为11到20毫秒,而处理时间(CLASS2)的时间约为1.4毫秒,CLASS 2的时间平均不到CLASS 1时间的十分之一。类似的,对于新增客户(Add Person)交易,CLASS 1的时间平均为CLASS 2时间的六倍。

因此可以得出结论:WebSphere Customer Center测试的应用在DB2内实际消耗的时间(Class 2)远小于交易的整体时间,DB2不是WebSphere Customer Center应用系统的瓶颈,对应用的整体消耗时间(response time)影响很小。

2.  数据库服务器压力(%)随同交易量稳定线性增长:

通过数据库服务器压力(%)除以吞吐量(TPS)可以得到数据库服务器平均每笔每秒交易所占CPU(%

图 6. 数据库服务器压力
数据库服务器压力
数据库服务器压力

上图可以看出, 基本查询(Get Person)在1000万数据情况下(黄色)和在5000万数据情况下(蓝色)基本一致,线性增长; 同样,新增客户(Add Person) 在1000万数据情况下(黄色)和在5000万数据情况下(蓝色)基本一致,线性增长;

可以得出结论,该系统的CPU开销随着交易量数量增加线性增长,对于基本查询(Get Person)交易,每增加一笔交易每秒,大约增加0.06%的CPU开销,即每个交易每秒约占用不到一个MIPS。对于新增客户(Add Person)交易,每增加一笔交易每秒,大约增加0.11%到0.15%的CPU开销,即每个交易每秒约占用约2个MIPS。

3.  数据库交易量的增加, 主机DB2处理性能稳定。

不论是Get Person交易还是Add Person交易,可以看出, 随着交易量的增加, DB2内部处理的时间(Class 2时间)始终稳定, 交易的整体响应时间的增加是由网络和应用引起的,与主机数据库几乎无关。从下图可以更加清楚地看到在交易量增加的情况下DB2 Class2时间仅仅有微小的波动。

图 7. 数据库处理时间
数据库处理时间
数据库处理时间

上图中, 可以看出, 在本次测试中,Add Person交易量的增加对于数据库的处理时间没有明显相关性,在交易量增加的情况下,数据库内部消耗时间始终稳定的保持在1.3ms到1.6ms之间。

图 8. 数据库处理时间
数据库处理时间
数据库处理时间

上图中, 可以看出, 在本次测试中,Add Person交易量的增加对于数据库的处理时间没有明显相关性,在交易量增加的情况下,数据库内部消耗时间始终稳定的保持在4ms左右(一千万数据量)或6毫秒左右(五千万数据量).

在本次测试中,数据量在五千万(客户实体树木)时的平均使用的Class 2时间要比一千万数据量时增加约2毫秒, 为此, 我们作了近一步比较分析

五千万客户量的ACCOUNT REPORT

一千万客户量的ACCOUNT REPORT

CPU TIME        0.005156    0.004420

 AGENT          0.005156    0.004420

  NONNESTED     0.005156    0.004420

CPU TIME        0.003175    0.002481

 AGENT          0.003175    0.002481

  NONNESTED     0.003175    0.002481

确认两者的主要差别在于CPU TIME, 这些时间的增加主要源于INDEX的PAGE SPLIT。由于数据量的增加, INDEX的LEVEL和SPLIT都会有所上升。合理的调整INDEX的分配, 将有助于降低这部分消耗。如果使用DB2 V9 for z/OS提供的新特性:IMPROVED PAGE SPLIT,也将会有较大的提升。

结论: 在本次测试中,交易量的增加对于数据库的处理时间没有明显相关性。在交易量增加的情况下,数据库内部消耗时间始终保持稳定。

4.  数据库数据量的增加, 主机DB2处理性能稳定

    本次测试中,分别测试了1000万客户实体数据量和5000万客户实体数据量两种情况, 在这两种情况下,分别在不同吞吐量的情况下测试了Get Person 和 Add Person,从下图可以看出无论是总体数据库服务器的响应时间response time(Class1)还是DB2内部处理时间(Class2)在1000万和5000万时的表现都很接近,始终保持在较低的水平线上。

图 9. 数据库处理时间
数据库处理时间
数据库处理时间

从上图可以看出, 对于Get Person交易,无论是一千万数据量还是五千万数据量,在吞吐量(横轴)增加的情况下,在主机DB2内部的消耗的时间基本一致,远远小于整体的response time。整体response time随着交易量的增加有一定上升,但这种上升与主机数据库无关。

图 10. 数据库处理时间
数据库处理时间
数据库处理时间

从上图可以看出, 对于Add Person交易,无论是一千万数据量还是五千万数据量,在吞吐量(横轴)增加的情况下,在主机DB2内部的消耗的时间基本一致,远远小于整体的响应时间。整体响应时间随着交易量的增加有一定上升,但这种上升与主机数据库无关。

更深入地分析

本次测试的结果,充分证明了的主机数据库的工作能力,在4个应用服务器较大的压力情况下,主机数据库提供了稳定的服务能力,数据库本身的响应时间在各种情况下,无论是数据量的增加(一千万到五千万客户实体),还是每秒访问的数据量的增加,主机数据库始终保持较快的相应能力。但应用总体的响应时间则随着节点数和交易量不断提高。通过DB2 Performance Monitor 的Accounting Trace看到基本查询交易Get Person的OPENS次数为6次,多次的进行OPEN工作,会对网络性能有一定的要求。

清单 1. DB2 Performance Monitor 输出
PRIMAUTH CORRNAME CONNECT   ACCT TIMESTAMP COMMITS   OPENS …
PLANNAME CORRNMBR THR.TYPE TERM. CONDITION SELECTS FETCHES …
-------- -------- -------- --------------- ------- ------- …
                                                           …
    -------------------------------------------------------…
    |REQUESTER         METH    TRANS  ROLLBCK  COMMITS  SQL…
    |9.181.157.124     DRDA        0        0        0     …
    -------------------------------------------------------…
                                                           …
TRAIN2   db2jcc_a SERVER   16:12:49.407605       1       6 …
DISTSERV ppli     DBAT     NORM DBAT INACT       0       9 …

为了提高运行的性能,建议生产使用千兆网络, 将会比测试中的结果有较大的提升。(本次测试中,由于条件限制,我们仅使用了百兆网络。)

此外,本次测试中,WebSphere Customer Center的所有应用均是通过JDBC TYPE4连接,进行数据库访问; 也即使用了基于TCP/IP的DRDA连接访问方式, 这种方式的负载, 如果使用最新的主机System z9, 可以通过zIIP卸载掉约40%的负载, 从而减少通用核心处理器CP的使用率, 极大的降低了主机使用成本。

zIIP是 2006年IBM 推出一种突破性的 IBM 大型主机专业引擎 - System z9 整合信息处理器(System z9 Integrated Information Processor,简称:zIIP)。System z9 整合信息处理器是一种运行特定数据库负载的专业引擎,它将能够帮助释放通用计算容量,并且降低商业智能(BI),ERP 和 CRM 等运行在大型主机上的指定负载的软件成本。

关于zIIP, 请见 参考资源

另外,要想最大限度的降低整体应用的响应时间,可以将WebSphere Customer Center部署在z系列主机上, 使用JDBC Type2 连接DB2, 这样的一体化结构,将会大大降低网络的影响,并提高应用的可靠性。

z/OS 引入了HiperSocket技术, 一种快速、高效的逻辑分区间数据传输手段,极大地提升了TCP/IP应用的性能,如果将WebSphere Customer Center和DB2都部署在主机上, 直接连接DB2,将可以获得更好的响应时间。而WebSphere Customer Center应用系统也会得益于主机的高可靠性,高稳定性,高可用性和高扩展能力。

图 11. 数据库处理时间
数据库处理时间
数据库处理时间

本次测试时,由于测试时间有限 ,我们只使用了纯JAVA的Type4 的方法连接。而对于网络压力比较大的应用,如果使用Type2(T2)的连接(如上图中红线), 由于几乎可以将网络时间全部省略,将会取得非常明显的良好效果,极大的降低整体响应时间。

总结

本次测试展示了主机数据库系统对新的应用的支持,通过JDBC技术,可以使开放的应用系统,非常方便的利用主机数据库提供的数据服务能力。测试结果表明,大型主机提供的数据服务能力是极其稳定的,在相当的范围内,无论数据量的大小,不论交易的增长,数据库的响应时间始终保持一致,几乎没有波动。大型主机的资源的消耗也非常稳定,每笔交易所占MIPS数目非常稳定,线性增长,利于系统未来的规划。

随着数据量高速膨胀,散乱于各个信息孤岛的数据不利于企业对信息的高层面的利用和管理,既浪费资源,又难以有效的综合利用;如今,数据集中已经逐步深入人心,全世界很多大型企业已经完成了全国乃至全球的核心应用的数据大集中;随着数据集中的实施,集中带来的信息处理和利用能力提高的同时,也带来了集中的风险,而集中的核心数据的安全与否直接关系到企业业务日常工作能否顺利进行。在这种背景情况下,越来越多的大型企业把目光放到主机的数据库上,使用主机的数据库作为企业级的数据服务中心已经成为一个理想的解决方案。这个方案的关键是整个企业的核心数据处理集中在一个高度可靠的数据服务器上。大型主机正是这样一个理想的数据服务平台。System z大型主机的数据库代表着业界最高的可用性,可靠性和高可扩展能力;采用Data Sharing技术的数据库的可用性指标可达99.999%,为确保企业的核心应用的安全和数据服务能力的成长可靠提供了有利的保障。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=260694
ArticleTitle=大型主机作为 WebSphere 客户中心数据服务器的测试分析
publish-date=09302007