bea白皮书 bea aqualogic data services...

BEA 白皮书——BEA AquaLogic Data Services Platform性能

- 1 -

BEA白皮书

BEA AquaLogic Data Services Platform™

性能

基于基准测试的案例分析


- 2 -

版权声明

1995–2005，BEA系统有限公司版权所有。保留所有权利。

有限权利说明本软件受版权法保护，还可能受专利法保护。没有获得BEA授权使用的许可协议，不得复制或以其他方式使用该软件。本文档受

版权法保护，未经BEA系统有限公司的事先书面许可，不得以影印、翻印、翻译或转换为任何电子媒体或机器可识别形式的方式，

部分或完整地复制本文档。本文档中的信息有可能不经声明地进行更改，而且不代表BEA系统有限公司的任何承诺。本文档是本文档是本文档是本文档是““““按按按按

现状现状现状现状””””提供提供提供提供的的的的，，，，不做任何不做任何不做任何不做任何形式形式形式形式的担保的担保的担保的担保，，，，包括包括包括包括不对适销性不对适销性不对适销性不对适销性、、、、特定用途的适用性特定用途的适用性特定用途的适用性特定用途的适用性做任何担保做任何担保做任何担保做任何担保。。。。此外此外此外此外，，，，BEABEABEABEA系统有限公司不对系统有限公司不对系统有限公司不对系统有限公司不对该文档的该文档的该文档的该文档的

使用或者使用结果使用或者使用结果使用或者使用结果使用或者使用结果在在在在正确性正确性正确性正确性、、、、准确性准确性准确性准确性、、、、可靠性或其他任何方面可靠性或其他任何方面可靠性或其他任何方面可靠性或其他任何方面做任何担保做任何担保做任何担保做任何担保、、、、保证或表述保证或表述保证或表述保证或表述。。。。

商标和服务标记列表 1995–2005，BEA系统有限公司版权所有。保留所有权利。BEA、BEA JRockit、BEA WebLogic Portal、BEA WebLogic Server、

BEA WebLogic Workshop、Built on BEA、Jolt、JoltBeans、SteelThread、Top End、Tuxedo和WebLogic是BEA系统有限公司的

注册商标。BEA AquaLogic、BEA AquaLogic Data Services Platform、BEA AquaLogic Enterprise Security、BEA AquaLogic Service

Bus、BEA AquaLogic Service Registry、BEA Builder、BEA Campaign Manager for WebLogic、BEA eLink、BEA Liquid Data for

WebLogic、BEA Manager、BEA MessageQ、BEA WebLogic Commerce Server、BEA WebLogic Communications Platform、BEA WebLogic

Enterprise、BEA WebLogic Enterprise Platform、BEA WebLogic Enterprise Security、BEA WebLogic Express、BEA WebLogic

Integration、BEA WebLogic Java Adapter for Mainframe、BEA WebLogic JDriver、BEA WebLogic Log Central、BEA WebLogic

Network Gatekeeper、BEA WebLogic Personalization Server、BEA WebLogic Personal Messaging API、BEA WebLogic Platform、

BEA WebLogic Portlets for Groupware Integration、BEA WebLogic Server Process Edition、BEA WebLogic SIP Server、

BEA WebLogic WorkGroup Edition、Dev2Dev、Liquid Computing和Think Liquid是BEA系统有限公司的商标。BEA Mission Critical

Support、BEA Mission Critical Support Continuum和BEA SOA Self Assessment是BEA系统有限公司的服务标记。其他名称和

标记属于其各自的所有者所有。

CWP1079E1105-1A


- 3 -

目录

执行概要.................................................................................................................................................................... 4

简介............................................................................................................................................................................ 5

查询处理架构............................................................................................................................................................ 6

数据服务性能要素.................................................................................................................................................... 8

零售客户自助服务基准测试.................................................................................................................................... 9

基准查询.......................................................................................................................................................... 10

配置.................................................................................................................................................................. 11

数据特征.......................................................................................................................................................... 11

基准测试结果.................................................................................................................................................. 12

集群化基准测试结果...................................................................................................................................... 15

结束语...................................................................................................................................................................... 17

附录 A....................................................................................................................................................................... 18

BEA AquaLogic Data Services Platform 中的大容量数据传输 ............................................................. 18

关于 BEA................................................................................................................................................................... 20


- 4 -

执行概要执行概要执行概要执行概要

本白皮书介绍了与BEA AquaLogic Data Services Platform 2.0.1相关的架构、查询处理技术和关键的性能因素。由实验所得的

结果深刻反映了一个基于零售消费者场景的示例应用程序的性能，说明了关键的系统性能特征，并演示了如何对底层的BEA

AquaLogic Data Services Platform项目进行此类分析。

所分析的示例应用程序涉及到一组读和写服务，这组服务集成了来自关系型数据源和基于Web服务的数据源的数据，并对这些

数据源应用更改。对于某些服务调用，为满足一个服务请求，可能有多达5个的异构源提供数据。变化的因素包括构成一个工

作负载的特定请求组合、工作负载强度（发出请求的客户端的数量）以及部署系统的集群的大小。

由所研究的示例应用程序及其变体所得出的重要发现可总结如下：

• 在单一服务器环境中，BEA AquaLogic Data Services Platform 2.0.1随着并发客户端数量的增加而呈线性伸缩。测

试得到的服务时间足够小（不到一秒），完全可以为所分析的系统中到处可见的交互式应用程序提供灵敏的响应能力。

总的吞吐量也如预期的一样随着系统负载的增加而呈线性伸缩。

• 在集群环境中，BEA AquaLogic Data Services Platform 2.0.1总的服务容量（吞吐量）随着部署平台的集群上硬件

的增加而呈线性伸缩。对于此类BEA AquaLogic Data Services Platform应用程序，集群化已经被证明是一种非常有

效的伸缩技术。

• 这些结论对只读工作负载和读-写工作负载都成立。

除了探讨BEA AquaLogic Data Services Platform 2.0.1系统的多用户性能之外，该白皮书还初步介绍了系统中现在所提供的

服务器端流式API的性能特征。公布了两组结果，一组涉及到得自多用户分析中所使用的、集成了5个源的数据服务的所有实例

（为了演示一个集成-流用例），另一组涉及来自单个底层源的数据（为了演示一个较为简单的流用例）。BEA AquaLogic Data

Services Platform 2.0.1被证明对两种流都非常有效。在两种用例中，都避免对数据进行完全具体化，这允许使用一个适度

的、与结果大小无关的内存配置来集成和流入大量数据。该系统被证明对简单和复杂的流用例都执行得非常好。


- 5 -

简介简介简介简介

本白皮书将简要概述BEA AquaLogic Data Services Platform 2.0.1中所使用的架构和查询处理技术，并介绍影响使用基于数

据服务的整合技术的应用程序的关键性能因素。

然后将描述使用BEA AquaLogic Data Services Platform 2.0.1进行的基准测试实践。该基准测试基于一个原型化的零售消费

者应用场景，它被设计得足够简单以便于理解，却又复杂得足以表示该平台所瞄准的应用程序和异构数据源场景。

本白皮书基于该基准测试提供了一些性能数据，这些数据解决了有关该平台的大量常见问题，以便帮助用户识别使用BEA

AquaLogic Data Services Platform 2.0.1开发项目时要考虑的关键因素。


- 6 -

查询处理架构查询处理架构查询处理架构查询处理架构

图1展示了该平台架构的概览。BEA AquaLogic Data Services Platform 2.0.1服务器（在图的中央）作为一个BEA WebLogic

Server®应用程序运行。在大多数情况下，客户端应用程序会请求平台服务器执行事先准备好的数据服务函数集合中的一个。

也支持特别查询。客户端请求可以通过该平台的任何API传入，包括Java mediator API、Web服务、BEA WebLogic Workshop®

Control或者是JDBC/SQL92 API。

图1 BEA AquaLogic Data Services Platform架构概览

数据服务函数和特别查询是使用XQuery语言编写的，用于对由企业的异构数据源所构成的基于XML的集成模型进行查询。在典型

场景中，数据服务架构预定义了该模型，以提供一组整洁、统一的与元数据集成的数据服务。这个数据服务层的组件用XQuery来

表示，正如SQL被用于定义关系数据库系统一样。BEA AquaLogic Data Services Platform提供了图形化的数据服务工具，以帮

助数据架构师和开发人员快速构造和测试XQuery数据服务和查询。该平台还支持通过它的所有API（JDBC/SQL92 API除外）进行

更新。

图2给出了BEA AquaLogic Data Services Platform查询处理架构的概览。在编译查询时，分布式查询处理器将XQuery请求转换

为优化的分布式查询计划。这涉及到解析和分析查询，展开或“折叠”其中所使用的任何视图的定义，然后对其进行优化以确定

底层的数据源请求的最佳集合，以及其他计算查询结果的中间处理步骤。然后查询处理器对相关的数据源执行所产生的查询操作

序列和/或函数调用。在执行查询操作时，服务器对从不同数据源返回的结果加以组合，形成单个的XML结果，并通过传入请求的

API将其返回给客户端应用程序。

BEA AquaLogic Data Services Platform查询处理器被设计得可以有效地对多个异构数据源执行查询操作。比起硬编码给定的

查询操作，使用该平台会带来较小的开销——实际上，使用分布式查询处理技术和高效的连接方法要远远优于普通开发人员在

硬编码的应用程序中所实现的查询操作。下面列出了BEA AquaLogic Data Services Platform所使用的关键查询处理技术：

SQL pushdownSQL pushdownSQL pushdownSQL pushdown。当从关系数据库访问数据时，BEA AquaLogic Data Services Platform会寻求将尽可能多的查询处理功能下放给


- 7 -

底层的每个关系数据库系统。这为每个系统提供了一个优化自己的查询部分而同时限制从每个源返回的中间数据的数量的机会。

查询操作——包括字符串搜索、比较操作、局部连接、排序、聚合函数和分组操作——都会尽可能地下放。

图2 BEA AquaLogic Data Services Platform查询处理概览

分布式连接方法分布式连接方法分布式连接方法分布式连接方法。当查询条件涉及到从两个或多个源获取数据时，BEA AquaLogic Data Services Platform使用一种或多

种分布式连接处理技术——批参数传递连接、索引连接和嵌套循环连接。

� 在批参数传递连接中，BEA AquaLogic Data Services Platform以批量形式从一个数据源传递连接值到另一个数据源，否则

的话连接将需要一个magni-tude命令或大量的SQL调用。当连接的右端是关系型数据源时，应该首选该连接方法。

� 在索引连接中，平台在一次调用中将一个连接目标全部取出放入BEA AquaLogic Data Services Platform服务器中，为生成

的数据建立索引，然后在本地执行连接。比起前一种方法，该技术涉及的远程调用较少，但是它需要更多的服务器内存，还

可能涉及到更多的数据移动。该方法用于连接的右端是非SQL源但是连接谓词要建立索引的场景。

� 在嵌套循环连接中，BEA AquaLogic Data Services Platform取出一个连接目标到服务器，然后通过对这个具体化的目标进

行循环而同时扫描其他连接目标来以本地方式执行连接。这种技术是最通用的，它一般都是最后考虑的，用于连接谓词不建

立索引的非SQL源。

慢速慢速慢速慢速数据源处理数据源处理数据源处理数据源处理。平台的运行时查寻引擎可以使用并行机制来减少涉及到慢速功能性数据源（比如远程Web服务或遗留后端系统

上的慢速应用程序视图）的查询操作的延迟。服务器包括一个异步请求管理器，它管理一个用于异步地对独立线程执行函数调用

的线程池，这减少了引擎的空闲时间，从而提升了查询操作的性能。当在要执行的查询表达式中包含async( )函数时，服务器将

创建查询计划来并行调用多个慢速函数。服务器还提供了timeout( )函数，可以用于在故障转移到一个备份表达式（例如，在初

始数据源无响应的情况下）之前限制服务器花在处理给定的XQuery表达式上的时间值。

数据数据数据数据服务结果缓存服务结果缓存服务结果缓存服务结果缓存。可以在每个查询操作的基础上配置BEA AquaLogic Data Services Platform，使其缓存任何数据服务函数

调用的结果。配置完之后，服务器就将函数结果保存在一个缓存数据库中，并根据函数名以及关联的参数值对其建立索引。数

据服务函数缓存适用于经常被调用的函数以及（在指定的生存期内）可以接受缓存结果的函数。当调用一个结果被缓存的函数

时，服务器可以快速取出并返回结果。这减轻了后端系统参与查询操作的负载，并提供了灵敏的查询操作响应能力。数据服务

函数缓存的典型用法是缓存来自高延迟Web服务调用或开销昂贵的数据集成函数的结果。

服务器集群化服务器集群化服务器集群化服务器集群化。BEA AquaLogic Data Services Platform是作为一个J2EE组件部署在BEA WebLogic Application Server基础架

构上的。因此，很容易使用Application Server Clustering特性扩展该平台。


- 8 -

数据服务性能要素数据服务性能要素数据服务性能要素数据服务性能要素

许多因素都影响着给定应用程序在 BEA AquaLogic Data Services Platform 上的总体服务器性能，包括下列方面：

� 应用程序所使用的数据服务和查询操作的复杂性

� 对数据源所执行的查询操作和更新操作的比例

� 底层数据源的性质，包括：

� 数据源的种类（关系型的或功能性的）；

� 调用开销（例如，调用一个临近的数据库与调用世界上某个地方的Web服务的开销不同）；

� 同一数据源上加载了多少来自其他应用程序的请求（例如，来自一个作为功能性数据源公开给平台的打包应用程序的用

户请求）；

� 请求所涉及的源数据量，以及其中有多少必须通过网络或从磁盘取得和/或转移到磁盘以进行响应。T

� 所部署的应用程序的预期并发用户数以及所产生的并发查询操作数。

其中的一些因素是由应用程序开发人员控制的，一些是由应用程序以及服务器集群的基础架构控制的，而另一些是IT环境中所

固有的——这是不能利用平台控制的。

例如，如果给定应用程序所有的数据源都是关系数据库，而且都由于其他对同一服务器的需求而负载沉重，那么BEA AquaLogic

Data Services Platform的性能将在很大程度上是由环境确定的。对于任何给定的请求，如果服务器花费了大部分时间去等待后

端源以数据响应，那么（除了启用数据服务结果缓存外）几乎不能做什么来调优性能或帮助系统扩展。

简单地说，应用程序性能的调优在很大程度上取决于请求的后端-服务器绑定与中间件-服务器绑定的程度。而这又依赖于请求可

以“推给”数据源的难易程度（对于关系型数据源来说，这又取决于请求的复杂性以及相关的数据源所使用的特定非标准语言）、

所产生的子查询操作的开销、数据源的响应速度、从数据源检索的数据量、有多少查询处理工作必须在服务器中执行，以及平台

的并发请求负载。

由于数据服务性能问题的复杂性，最好是弄清楚起作用的力量和因素，对给定的应用场景中所发生的事情做出合理的推测。当然，

强烈推荐在概念验证(Proof of Concept，POC)过程中体验应用程序本身。这里提供的信息旨在帮助您根据对关键问题的推理来

选择针对任何给定POC的适当作用域——并从而决定需要研究哪些尚未解决的性能问题。


- 9 -

零售零售零售零售客户客户客户客户自助自助自助自助服务基准测试服务基准测试服务基准测试服务基准测试

为将理论付诸实践，可考虑一个示例应用程序，可以用它来衡量BEA AquaLogic Data Services Platform上客户端查询数据源以

及加载客户端查询操作和更新操作的混合工作负载时的实际性能。无疑，任何给定的应用程序都与该例子不同，所以实际的结果

也会不同。但是它确实提供了两个“合理”的数据集，说明了所讨论的一些因素所造成的影响。

此外，该基准应用程序中的数据服务函数（查询）、更新和数据源都是BEA客户可能使用BEA AquaLogic Data Services Platform

的典型方式（至少从近期来说是这样的）——即，使用该平台创建支持来自于数据库和/或Web服务的整合数据以供基于SOA的Web

应用程序访问和实时更新的统一服务。

一个假想的、直接基于BEA AquaLogic Data Services Platform所附带的示例应用程序的零售客户自助服务应用程序将被用于

该基准测试（零售客户自助服务——即CSS——基准测试）的两个场景。该应用程序提供一个基于Web的客户自助服务门户，它

显示了给定客户的个人信息、信用等级、来自假想公司的电子和服饰类订单管理系统的订单、注册的信用卡、送货地址和服务

情况。图3显示了该基准应用程序的总体架构。

图3 Retail CSS Benchmark概览

Retail CSS Benchmark应用程序涉及到分布在4个关系型数据源和两个Web服务的数据。4个关系型数据源是：

Customer（客户）数据库——包含客户的个人数据和送货地址。

Billing（账单）数据库——包含客户的注册信用卡

Service（服务）数据库——包含服务情况

Apparel Order（服饰类定购）数据库——包含服饰类定购的订单及线项目(line item)


- 10 -

两个Web服务：

1 Electronics Order（电子类定购）Web服务——返回电子类定购的订单及线项目。使用一个关系数据库（非常类似于

Apparel Order数据库）保存订单信息。

2 Credit rating（信用等级）Web服务——返回客户的信用等级信息。

基准查询基准查询基准查询基准查询

Retail CSS Benchmark用于两个场景。首先是一个由5个“典型”的此类应用程序的数据服务请求组成的纯查询场景。这5个

查询函数见表1所示。

表1：查询函数

基准请求基准请求基准请求基准请求结果大小结果大小结果大小结果大小查询查询查询查询函数函数函数函数描述描述描述描述（（（（包括数据源包括数据源包括数据源包括数据源））））

Customer Profile 4K 返回包括地址和信用卡的客户信息(2个关系数据库管理系统)

Electronics Order Detail 3K 返回电子类定购的包含线项目的订单以及账单和送货信息(2个关系数据库管理系统，

1个Web服务)

Customer Credit Rating 1K 返回客户信息以及客户的信用等级(1个关系数据库管理系统，1个Web服务)

Apparel Order Detail 3K 返回服饰类定购的包含线项目的订单以及账单和送货信息(3个关系数据库管理系统)

Login Customer View 4K 返回给定客户当前的所有公开定购和公开情况(4个关系数据库管理系统，1个Web服

务)

Customer Profile（客户个人信息）查询函数检索填充“我的账户信息”自助服务Web页面所需的信息。Electronics Order Detail

（电子类定购详情）和Apparel Order Detail（服饰类定购详情）查询函数检索定购详情（对于电子类，是从Web服务中；而对

于服饰类，是从关系数据库管理系统中——这是二者惟一重要的区别）以及相关的地址信息。Customer Credit Rating（客户信

用等级）查询函数组合了一个Web服务调用和两个数据库调用，Login Customer View（登录客户视图）查询函数检索填充“我的

公开定购”自助服务Web页面所需的信息。Retail CSS Benchmark的全部工作负载包含这5个查询函数的等量混合，基准测试既度

量了单个查询函数的性能，也度量了整个组合的性能。如表1所示，这些查询函数在所访问的数据源的数量和性质方面各不相同。

使用Retail CSS Benchmark的第二个场景结合了写操作来模拟混合工作负载环境。调用了同样的5个读查询函数，构成了工作负

载的80%，其余的20%则分布在表2底端所列出的3个新的写操作上。每一组（80%的读，20%的更新)内的请求都在各自的组内平均

分布。

Customer Email Update（客户电子邮件更新）操作检索给定客户的个人信息，然后提交电子邮箱地址的更改。New Apparel Order

（新服饰类定购）和New Electronics Order（新电子类定购）操作各自添加一个包含1到5个线项目的新客户订单。对于每个New

Order操作，有20%的时间定购是来自新客户的。在这种情况下，在创建新订单之前要执行新客户插入操作。所有的更新和插入操

作都是使用BEA AquaLogic Data Services Platform客户端SDO API完成的。New Electronics Order操作需要使用BEA AquaLogic

Data Services Platform更新重写来将订单插入转换为适当的Web服务调用。

这两个场景还将在集群化可伸缩性测试中使用，在该测试中，BEA AquaLogic Data Services Platform实例数将会增加（每一个

单独的服务器机器上有一个实例）。

表2：查询函数和更新操作

基准请求基准请求基准请求基准请求结果大小结果大小结果大小结果大小查询函数查询函数查询函数查询函数描述描述描述描述（（（（包括数据源包括数据源包括数据源包括数据源））））

Customer Profile 4K 返回包括地址和信用卡的客户信息(2个关系数据库管理系统)

Electronics Order Detail 3K 返回电子类定购的包含线项目的订单以及账单和送货信息(2个关系数据库管理系统，


- 11 -

1个Web服务)

Customer Credit Rating 1K 返回客户信息以及客户的信用等级(1个关系数据库管理系统，1个Web服务)

Apparel Order Detail 3K 返回服饰类定购的包含线项目的订单以及账单和送货信息(3个关系数据库管理系统)

Login Customer View 4K 返回给定客户当前的所有公开定购和公开情况(4个关系数据库管理系统，1个Web服

务)

Customer Email Update 0K 更新客户电子邮件信息(1个关系数据库管理系统)

New Apparel Order 0K 插入给定客户的新服饰类订单(3个关系数据库管理系统)

New Electronics Order 0K 插入给定客户的新电子类订单(2个关系数据库管理系统，1个Web服务)

配置配置配置配置

基本的Retail CSS Benchmark运行在一个机器网络上，其中有3台驻留关系数据库的机器，一台驻留两个Web服务的机器，一台驻

留BEA AquaLogic Data Services Platform服务器的机器，以及一台生成合成并发客户请求工作负载的机器（如图3所示）。表3

列出了所使用的机器和软件的详情。BEA AquaLogic Data Services Platform服务器配置本身在自己的服务器机器上使用了一个

BEA AquaLogic Data Services Platform服务器实例。BEA WebLogic Server实例使用的是BEA JRockit v1.4.2.05，最小和最大

内存都设为1GB，采用默认的BEA WebLogic Server配置，将并发客户端请求线程数设为30。BEA AquaLogic Data Services Platform

服务器机器的JDBC配置使用Oracle 9.2.0.2 Thin Driver、MS SQL驱动程序以及BEA WebLogic Server的Sybase驱动程序；每个

的JDBC连接池大小都设为30。客户端工作负载是使用为AquaLogic Data Services Platform质量保证用途而定制开发的BEA

AquaLogic Data Services Platform工作负载生成工具生成的。

表3：机器配置

机器功能机器功能机器功能机器功能软件版本软件版本软件版本软件版本数据库服务器机器数据库服务器机器数据库服务器机器数据库服务器机器

Electronics Order数据库 Oracle 9.2 Win2K，2 CPU，2 GHz，2GB内存

Apparel Order数据库 Oracle 9.2 Win2K，2 CPU，2 GHz，2GB内存

Service数据库 MS SQL 2000 Win2K，2 CPU，2 GHz，2GB内存

Customer数据库 Sybase 12.5.2 Win2K，2 CPU，2 GHz，2GB内存

Billing数据库 Oracle 9.2 Win2K，2 CPU，2 GHz，2GB内存

Electronics Order Web服务 BEA WebLogic Server 8.1 SP4 Win2K，2 CPU，2 GHz，2GB内存

Credit Rating Web服务同上同上

BEA AquaLogic Data Services

Platform数据整合服务器

BEA AquaLogic Data Services Platform DSP

2.0.1 Redhat Linux，2 CPU，2 GHz，2GB内存

生成客户端工作负载

BEA AquaLogic Data Services Platform QA测

试驱动程序 Win2K，2 CPU，2 GHz，2GB内存.

表4总结了对Retail CSS Benchmark运行测试时所使用的数据库的基本特征。

数据特征数据特征数据特征数据特征

每个数据库表都有一个主键，二级索引直接建立在外键上，用于查询。

表4：数据特征

名称名称名称名称数据库数据库数据库数据库////版本版本版本版本

Customer Data 10K customers，20K addresses


- 12 -

Billing Data 20K credit cards

Apparel Order Data 100K orders，300K line items

Electronics Order Data 100K orders，300K line items

Service Case Data 3K service cases

此外，还运行了一个扩展的Retail CSS Benchmark，以展示BEA AquaLogic Data Services Platform的集群化特征。该配置使

用了1个、2个和3个BEA AquaLogic Data Services Platform服务器实例，每一个实例都驻留在单独的同类型服务器机器上。

基准测试结果基准测试结果基准测试结果基准测试结果

为了研究BEA AquaLogic Data Services Platform在现实负载下的性能，Retail CSS Benchmark查询和更新是从可变数量的客户

端运行的。请求之间的客户端思考时间从2秒变化到18秒（平均是10秒）。并发的活动客户端的数目在实验中是从1变化到1600。

每个客户端等待一段随机的思考时间，发出一个请求，该请求被Retail CSS的整体请求分发获取，然后客户端等待接收平台的响

应，之后再重复思考和请求过程。（注意，一旦客户端数超过800，客户端生成程序就被分开在两个JVM上，以确保工作负载的生

成可扩展。）测试运行得足够长，足以产生稳定的性能度量——即，足以避免启动/关闭时产生的并发工作负载“边缘效应”。

纯查询工作负载

表5显示了在不同的并发等级下执行不同的查询函数所得到的响应时间（以秒为单位）。它还显示了在这些工作负载下的总的平

均响应时间（以秒为单位）以及相应的吞吐量（以查询/秒为单位）。

表5：纯查询工作负载数据

查询函数查询函数查询函数查询函数客户端个数客户端个数客户端个数客户端个数

1 400 800 1200 1600

Apparel Order Detail 0.0156 0.0201 0.0237 0.0344 0.0446

Electronics Order

Detail 0.0157 0.0255 0.0351 0.0469 0.0638

Customer Profile 0.0078 0.0088 0.0139 0.0223 0.0321

Customer Credit Rating 0.0027 0.0046 0.0096 0.0193 0.0274

Login Customer View 0.0313 0.0359 0.0469 0.0609 0.0737

平均响应时间（秒） 0.015 0.019 0.0258 0.0368 0.0483

吞吐量（查询/秒） 0.11 42.14 84.59 124.80 167.63

对于单个查询结果，有几点需要注意。首先，很明显，BEA AquaLogic Data Services Platform能够非常快速地运行所有查询

函数，提供比此类Web应用程序所需要的更快的响应能力。一直到客户端个数线性增长到1600，所有查询操作的响应时间都不超

过0.1秒。

其次，正如预期的一样，单个查询操作的性能随着所访问的数据源的数量和性质而变化。例如，Login Customer View查询操作

是到目前为止最慢的，尤其是在负载较轻时，它的较长的固有延迟是最明显的。该查询操作涉及到访问来自4个关系型数据源的

信息以及通过一个Web服务与一个应用程序交互（底层应用程序反过来又访问来自另一个服务器上的内部关系数据库管理系统的

数据）。将其与Apparel Order Detail查询操作相比较，在执行后者时BEA AquaLogic Data Services Platform直接与3个关系

数据库管理系统数据源交互。Customer Profile和Customer Credit Rating由于涉及的工作量少而执行得最为轻快，因此性能

最好。

图4中的两个图显示了总体平均响应时间和相应的吞吐量如何随着系统上负载的变化而变化。从这些结果可以看出，BEA

AquaLogic Data Services Platform对此类应用程序的可伸缩性很好。响应时间随着负载的增加而呈线性增长。吞吐量也呈线

性增长，而不是在达到某个点后就变得平稳，这表明更高的负载也是可以接受的，总体系统延迟并不影响响应时间。


- 13 -

图4 总体平均响应时间和相应的吞吐量

混合工作负载

为了解BEA AquaLogic Data Services Platform服务器在混合工作负载环境中的性能，我们另外编写了3个写操作并将其添加到

基本的Retail CSS Benchmark中。使用的基本配置参数（即，随机的思考时间、并发客户数、避免边缘效应等等）同上。查询操

作和更新操作是分别按照80/20的比例随机选择的，然后每个特定的查询操作或更新操作是从它的请求组内随机选择的。表6说明

了每个请求的响应时间以及总体平均响应时间（以秒为单位）。还列出了总的吞吐量（以查询/秒为单位）。

将表6中的前5个查询操作的响应时间与表5中的响应时间相比较，几乎所有的查询操作花费的时间都变长了，这种现象随着客户

端负载的增加而变得更普遍了。这种行为是可以预见的：添加的更新操作要求必须将数据写入磁盘，这增加了系统负载，从而降

低了整个系统的响应灵敏度。在低系统负载下，Login Customer View查询操作的响应时间与两个Add Order操作的响应时间近似

相等，但是最终Add Order操作的响应时间开始超过Login Customer View查询操作的响应时间。这种行为是可以预见的，即使Login

Customer View查询操作访问了5个数据源且检索的数据较多。Add Apparel Order操作需要2到6个插入语句，而Add Electronics

Order需要一次Web服务调用以及2到6个关系型插入语句。此外，20%的新订单会添加新的客户，这需要对另外两个数据源的插入

操作以及添加2个或3个网络跃点。对比之下，最小的更新操作Customer Email Update只更新了单个数据源中的单个表的一行，

因此其总体响应时间比较短。该更新请求的响应时间可与读取两个数据源的Customer Profile查询操作相比。

表6：查询操作和更新工作负载数据

查询操作查询操作查询操作查询操作客户端个数客户端个数客户端个数客户端个数

1 400 800 1200 1600

Apparel Order Detail 0.0160 0.0223 0.0310 0.0480 0.1027

Electronics Order Detail 0.0195 0.0277 0.0436 0.0623 0.1212

Customer Profile 0.0124 0.0129 0.0215 0.0357 0.0704

Customer Credit Rating 0.0030 0.0080 0.0168 0.0297 0.0750

Login Customer View 0.0310 0.0410 0.0566 0.0757 0.1389

Add Apparel Order1 0.0310 0.0532 0.0662 0.1001 0.1814

Add Electronics Order 0.0315 0.0497 0.0634 0.0869 0.1503

Customer Email Update 0.0075 0.0118 0.0242 0.0367 0.0834

总体平均响应时间（秒） 0.0173 0.0257 0.0376 0.0554 0.1027


- 14 -

查询操作平均响应时间（秒） 0.0163 0.0223 0.0339 0.0503 0.1017

更新操作平均响应时间（秒） 0.0218 0.0382 0.0513 0.0746 0.1384

吞吐量（查询/秒） 0.10 41.88 84.21 125.55 166.59

注1：正如预期的一样，Apparel Order Detail 查询操作要比Electronics Order Detail 查询操作快，因为从关系数据库管理系统读取数据通常要比从

Web服务读快。但是，这对于更新操作来说未必正确：Add Apparel Order 更新操作要比Add Electronics Order 更新操作慢。该Web服务更新操作使用了

一个对特定操作硬编码的更新重写，而关系数据库管理系统更新操作使用了自动的更新分解框架来传播更新。

系统的总体吞吐量随着增加的更新操作差不多呈线性增长，非常接近于查询工作负载的吞吐量。注意，在现实系统中，总体吞吐

量无疑会随着写操作的比例而改变。基准程序设计者选择了一个包含20%写操作的假想系统。2

（注2：20%的写操作对应于TPC-W基准所

使用的比例。）

图5显示了总体平均响应时间以及相应的吞吐量随系统负载的增加而变化的情况。像对只读工作负载应用程序一样，BEA

AquaLogic Data Services Platform对混合工作负载应用程序的可伸缩性也非常好。

图5 总体平均响应时间以及相应的吞吐量

图6比较了查询工作负载与混合工作负载的响应时间。其中，在客户端个数较少时，增加了写操作的工作负载的响应时间几乎与

读操作工作负载的响应时间具有相同的增长速率；但是，最终前者的响应时间增长得更快，曲线变得更陡。因此，系统的总体响

应灵敏度随着更新操作比例的增加而降低，这是由于数据源向磁盘进行I/O延长了延迟。

图6 查询工作负载与混合工作负载的响应时间


- 15 -

集群化集群化集群化集群化基准测试基准测试基准测试基准测试结果结果结果结果

为研究可伸缩性，我们将BEA AquaLogic Data Services Platform实例数从1增加为3。每个实例都部署在自己的服务器机器上，

所有的机器都具有同样的速度和内存。所使用的客户端的个数被设置为1600乘以平台实例数——前面单实例的最高负载。

纯查询工作负载

表7说明了不同的BEA AquaLogic Data Services Platform集群配置下的纯查询工作负载的总体吞吐量（以查询/秒为单位）。

表7：集群纯查询工作负载数据

查询查询查询查询工作负载工作负载工作负载工作负载

(1600(1600(1600(1600个客户端个客户端个客户端个客户端 ×××× K K K K个实例个实例个实例个实例))))

1111个实例个实例个实例个实例 2222个实例个实例个实例个实例 3333个实例个实例个实例个实例

总吞吐量 169.63 332.68 474.37

随着向集群添加新的BEA AquaLogic Data Services Platform实例，系统总体吞吐量合计呈线性增长3

，正如一个良好的分布式系

统所应该表现的那样。如图7所示，随着新的BEA AquaLogic Data Services Platform实例的添加，吞吐量也随之增长。（注3：

受硬件限制，不能进一步测试集群的可伸缩性了。）

图7 集群查询工作负载吞吐量

混合工作负载

表8表示了混合工作负载下的总体吞吐量（以查询/秒为单位）。

集群总体吞吐量也如预期的一样是呈线性增长的。再次地，纯查询工作负载与混合工作负载之间的吞吐量差别可以忽略不计。

表8：集群混合工作负载数据

查询查询查询查询工作负载工作负载工作负载工作负载

(1600(1600(1600(1600个客户端个客户端个客户端个客户端 ×××× K K K K个实例个实例个实例个实例))))

1111个实例个实例个实例个实例 2222个实例个实例个实例个实例 3333个实例个实例个实例个实例

总吞吐量 166.59 327.31 473.82

图8 集群混合工作负载吞吐量


- 16 -


- 17 -

结束语结束语结束语结束语

本白皮书介绍了BEA AquaLogic Data Services Platform 2.0.1的架构和性能特征。具体来说，讨论了该平台为有效处理整合了

来自各种分布式数据源的数据的请求所使用的技术。使用了一个基于原型的零售消费者应用场景的多用户基准程序，以及在查询

和混合工作负载环境中运行BEA AquaLogic Data Services Platform 2.0.1所得出的结果。基准测试的结果显示，BEA AquaLogic

Data Services Platform 2.0.1为此类场景提供了快速的查询操作响应能力，而且随着用户负载的增加，该平台具有良好的可伸

缩性。对于包含查询操作和更新操作的混合场景，也有类似的结果。还研究了BEA AquaLogic Data Services Platform服务器集

群的情况，系统的客户端请求容量接近于呈线性扩展。上述所有场景的基准测试结果表明，可以预见到，在现实的消费者场景中，

BEA AquaLogic Data Services Platform 2.0.1会运行得相当好。


- 18 -

附录附录附录附录 A A A A

BEA AquaLogic Data Services Platform中的大容量数据传输 BEA AquaLogic Data Services Platform有附加的、用于各种场景的、处理大型数据集的功能。大型数据集可能由来自多个数

据源的数据聚合而成，可能来自没有筛选谓词的数据源（即，提取整个数据集），或者来自于一个专门为从操作型大型机系统

提取数据而构建的物理数据源。在这些情况下，吞吐量在很大程度上是由前述的一些因素所决定的，即：

� 应用程序所使用的数据服务和查询操作的复杂性

� 底层数据源的性质，包括：

� 数据源的种类（关系型的或功能性的）；

� 调用开销（例如，调用一个临近的数据库与调用世界上某个地方的Web服务的开销不同）；

� 同一数据源上加载了多少来自其他应用程序的请求（例如，来自一个作为功能性数据源公开给平台的打包应用程序的用

户请求）；

� 所部署的应用程序的预期并发用户数以及所产生的并发查询操作数。

为了说明可以预期的吞吐量值的范围，使用了两个非常不同的数据服务。第一个针对一个“单视图”风格的门户，有选择地聚

合了来自多个数据源的信息。特别是，在前面的分析中所使用的Login Customer View 这次也用上了。BEA AquaLogic Data

Services Platform服务器流式API访问该视图以从该数据服务选择所有的实例——例如，用于存档。返回的数据是未经处理的，

只探讨其流性能。（通常，返回的数据应该被搜索、分段并/或写入文件。）

第二个数据服务以一列2000个字节的形式呈现了从一个关系型数据源选择的数据。这个相当简单的数据服务用于创建一种性能不

受慢速后端或复杂集成限制的场景，从而探查BEA AquaLogic Data Services Platform从单个后端数据源获取流式数据的速度。

表9列出了所用的时间以及获取的数据量（以MB为单位）。所达到的不经处理的最大数据流入速率大约是21 MB/秒。对于CustView，

没有最大的结果大小，因为基准测试的数据集包含的数据不足以产生那么大的结果。

表9：从单个后端数据源流入的数据

MB Data Transferred 0.003 0.043 0.444 4.534 23.17 46.386 92.77

Aggregated CustView 0.01 0.06 0.075 0.082 0.081 0.08 不可用

Pure Streaming 0.03 0.28 2.66 13.14 21.634 21.6 21.93

图9所示的结果表明，BEA AquaLogic Data Services Platform 2.0.1中流入数据的总体吞吐量范围很广，而且实际上取决于上

面所列出的因素。在两种用例中，BEA AquaLogic Data Services Platform都能够高效地流入数据，其总体性能取决于流入数据

的服务的复杂性。两种情况都避免对数据进行完全具体化，允许使用与结果大小无关的内存配置整合并流入大量数据。

图9 流入数据的总体吞吐量


- 19 -


- 20 -

关于关于关于关于 BEA BEA BEA BEA

BEA系统有限公司(NASDAQ: BEAS)是全球领先的企业基础架构软件公司，它提供了一组基于标准的平台以促进信息和服务的安全

流动。BEA产品线——WebLogic®、Tuxedo®、JRockit®以及新的AquaLogicTM Service Infrastructure产品家族——能够帮助客

户降低IT复杂性并成功地部署面向服务架构，以提高业务敏捷性和效能。更多信息请访问 bea.com.cn。


- 21 -

BEA Systems, Inc.

2315 North First Street San Jose, CA 95131

+1.800.817.4232 +1.408.570.8000

bea.com CWP1079E1105-1A

bea白皮书 bea aqualogic data services...

Documents