DB2 9 XML 性能特征

新客网 XKER.COM 2006-08-27 来源：收藏本文

表 6. 混合工作负载的事务

#	名称	类型	占总量的百分比
1	get_order	查询	10
2	get_security	查询	10
3	customer_profile	查询	10
4	search_securities	查询	10
5	account_summary	查询	10
6	get_security_price	查询	10
7	customer_max_order	查询	10
8	upd_custacc	更新	3
9	upd_security	更新	3
10	del_custacc	删除	2
11	del_order	删除	10
12	insert_custacc	插入	2
13	Insert_order	插入	10

更新事务首先根据一个 XQuery 谓词读取一个特定文档，然后使用它更新数据库中这个文档的原副本。在实际情况下，在读取和更新步骤之间会更新文档，但是这与本文的目的没什么关系，因此为了简化省略了这个步骤。

在执行插入时不进行 XML 模式检验。

更新和删除操作所针对的文档是在数据库中随机选择的。每个新插入的订单和 CustAcc 文档马上可以被后续的事务更新或删除。

回页首

结果

数据库设置和所有工作负载不间断地连续执行。23 小时的不间断系统测试的结果见表 7。

表 7. 使用所有工作负载的全面测试的计时

任务	花费的时间（分钟）	解释/说明
创建数据库和更新数据库配置	1	-
插入工作负载	160	所有阶段的总时间
在表和索引上运行 stats	340	时间的分布如下： 22 分 - 证券 2 小时 45 分 - CustAcc 2 小时 54 分 - 订单
数据库备份	23	-
查询和混合工作负载	825	这两个工作负载都使用 25、50、75、100、125 和 150 个用户运行
数据库恢复	17.5	-
其他	~15	其他各种任务
总时间	~1380	总运行时间为 23 小时

插入工作负载的结果

插入 36,020,833 个文档花费的总时间大约是 160 分钟，产生的平均吞吐量是每秒 3770 个插入。吞吐量随文档的大小而变化：

插入这两种文档的数据量速度都是大约每小时 30GB。图 2 显示随着订单数量增长到 300 万个文档，订单插入的速度几乎保持不变。

图 2. 订单文档的插入速度

查询工作负载的结果

查询工作负载的性能随着用户数量的增加和更好地利用 CPU 而增加。正如预期的，随着 CPU 利用率接近 100%，吞吐量曲线逐渐变平。最好的吞吐量出现在有 150 个用户的情况下，在 CPU 利用率为 96% 时达到每秒 5480 个查询，见图 3。

将用户数量增加到 175 并不会使吞吐量显著提高，因为机器已经达到满负荷了。

图 3. 只读查询吞吐量、CPU 利用率和 I/O 等待时间

混合工作负载的结果

混合工作负载最好的性能也出现在有 150 个并发用户时，见图 4。吞吐量是每秒 1980 个事务。正如预期的，混合工作负载的吞吐量比纯查询和纯插入工作负载低。

图 4. 混合工作负载吞吐量、CPU 利用率和 I/O 等待时间

回页首

结束语

这次性能研究的目的是，在使用最新的 IBM 服务器硬件、存储、AIX 操作系统和 DB2 9 软件的情况下，演示 XML 工作负载的操作性能特征。所有测试都使用 DB2 新的 STMM 和自动存储特性。

我们觉得，对于包含基于消息的事务处理的 XML 应用程序以及处理大量小 XML 文档的 Web 服务应用程序，这个工作负载场景是有代表性的。选择金融业是因为我们在这方面有经验，而且它采用了一种成熟的标准化的 XML 模式 —— FIXML。

下面对测试的情况做一下总结：

总测试时间为 23 小时，包括创建数据库。
测试数据由 600 万个 CustAcc 文档、3000 万个订单文档和 20833 个证券文档组成。
测试分别采用 25、50、75、100、125 和 150 个并发用户。
插入吞吐量（每秒事务数，即 tps）随文档的大小而变化，但是在一个大小内是线性的。吞吐数据量稳定在每小时 30GB，与文档大小无关：

共5页: 上一页 [1] [2] [3] [4] [5] 下一页

【收藏】【评论】【推荐】【投稿】【打印】【关闭】