科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道DB2 9 XML 性能特征(1)

DB2 9 XML 性能特征(1)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

既然 DB2 9 发布了,现在是时候对它的最新特性之一 —— pureXML? 进行测试驱动了。为此,建立了一个模拟的经纪业务环境。

作者:Irina Kogan 来源:IT专家网 2008年6月4日

关键字: IBM 数据库 DB2

  • 评论
  • 分享微博
  • 分享邮件

表 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 个插入。吞吐量随文档的大小而变化:

订单文档(1K 到 2K)以平均每秒 5320 个插入的吞吐量插入。
帐号文档(3K 到 10K)以平均每秒 1550 个插入的吞吐量插入。
插入这两种文档的数据量速度都是大约每小时 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,与文档大小无关:
1550 tps(CustAcc 文档,4K 到 20K)
5320 tps(订单文档,1K 到 2K)
查询吞吐量随并发用户数量伸缩:
25 个用户时 2000 tps
150 个用户时 5500 tps(CPU 利用率最大,I/O 等待时间接近零)
混合事务吞吐量也随并发用户数量伸缩,直到大约 2000 tps:
25 个用户时 1000 tps
150 个用户时 2000 tps(~42% 的CPU 利用率,~50% 的 I/O 等待时间)。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章