分类：
2008-04-24 09:49:00
在插入负载填充数据库之后，对数据库执行一个只读的工作负载。这个工作负载由 7 个 XML 查询组成，使用 25、50、75、100、125 和 150 个并发用户以不同的并发度执行。测试的时间长度是这 6 个测试各运行一个小时。
7 个查询都具有以下特征：
它们都是用符合标准的 SQL/XML 表示法编写的，比如带有嵌入式 XQuery 的 SQL，利用了参数标志。更多信息请参考 Advancements in SQL/XML。
它们使用 SQL/XML 谓词 XMLEXISTS 根据一个或多个条件选择 XML 文档，条件用 XQuery 表示法表示。
它们使用 SQL/XML 函数 XMLQUERY 检索完整的或部分 XML 文档，或者构造与数据库中存储的文档不同的结果文档。
它们使用与 XML 数据中的名称空间对应的 XML 名称空间。
它们利用一个或多个 XML 索引完全避免表扫描。
这 7 个查询在工作负载中具有同样的权重。
表 5 显示这 7 个查询的特征差异和它们涉及的表。
表 5. XML 查询小结
| Q | 查询名 | CustAcc | Security | Order | 特征 |
|---|---|---|---|---|---|
| 1 | get_order | - | - | X | 返回完整的订单文档，但是没有 FIXML 根元素。 |
| 2 | get_security | - | X | - | 返回完整的证券文档。 |
| 3 | customer_profile | X | - | - | 提取 7 个客户元素来构造概况文档。 |
| 4 | search_securities | - | X | - | 根据 4 个谓词从一些证券中提取元素。 |
| 5 | account_summary | X | - | - | 构造一个帐号说明。 |
| 6 | get_security_price | - | X | - | 提取一种证券的价格。 |
| 7 | customer_max_order | X | - | X | 联结 CustAcc 和订单，寻找一位客户的最大订单。 |
混合工作负载：读/写
与只读工作负载相似，混合工作负载针对填充的 600 万个 CustAcc 文档和 3000 万个订单执行，并使用 25、50、75、100、125 和 150 个并发用户产生不同的并发度。测试的时间长度是每个测试各运行一个小时。
混合工作负载由以下操作组成：
70% 的读操作：查询
30% 的写操作：6% 的更新操作，12% 的文档删除操作，12% 的插入操作。
查询与上面的只读工作负载中的查询完全一样，下面是定义更新/删除/插入事务时考虑的情况：
更新客户帐号以反映交易（订单的执行），但是不需要在每个订单之后立即执行（3% 的 CustAcc 更新）
在我们的场景中不更新订单文档（因此没有订单更新事务）
在交易时间定期更新证券的价格（3% 的证券更新）
客户的插入和删除少（2% 的 CustAcc 插入，2% 的 CustAcc 删除）
新订单不断到达，旧订单从系统中删除，两者的速率是相同的（10% 的订单插入，10% 的订单删除）
证券种类的数量是固定的（没有删除和插入事务）
通过考虑这些目标，产生了表 6 所示的事务组合。
表 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 个插入。吞吐量随文档的大小而变化：
订单文档（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 等待时间）。
