引言

IBM? Rational? ClearQuest? 缺陷及变更追踪系统会获取并追踪项目中所有类型的变更。Rational ClearQuest Web 功能通过基于网络的界面来访问储存库。

性能通常来说是 Rational ClearQuest Web 客户的关注点。在部署新 IBM? Rational? ClearQuest? 版本之前，客户通常会测试新版本是否满足他们的性能需求。如果不满足，那么他们会试着决定性能问题的来源，并做需要的性能调试操作。

Rational ClearQuest Web 7.1 架构会随着 Web 2.0 技术及 Change Management（CM） Server（变更管理服务器）的引入而发生显著的变化。由于这些架构上的变更，Rational ClearQuest Web v7.0 性能测试及调试技术（这就是说，CQWeb：性能与同时 中所描述的技术）不再适用于 7.1 版本。
本文描述了性能测试，及调试 Rational ClearQuest Web 7.1 的系统性方法。本文之中的大多数内容可以通过在客户网站上使用来进行确认。

Rational ClearQuest Web 7.1 之中的不同内容

Rational ClearQuest Web 7.1 中主要有两点差异，会影响到性能测试及调试方法：

• 富客户端（Rich Client）。 前面版本之中的网络客户端是一个终端，它会简单地从服务器那里获得 HTML。但是，7.1 版本之中的客户端是一个 Web 2.0 客户端，将状态和数据存储在浏览器内存之中，并与 JavaScript Notation（JSON）格式的服务器相交流。该灵巧客户端会缓存再使用数据，异步预取需要的数据，延缓初始化直到需要对象为止（也叫做“载入缓慢”），等等。由于这些特性的存在，测试工具测试的性能不同于用户预期的性能。
• CM Server。 它为 Rational ClearQuest 与 IBM? Rational? ClearCase? WAN 界面提供了服务器端的支持。它替换了 ClearQuest Web 7.0 版本之中的 Request Manager，并拥有来自该版本的不同调试指南。Rational ClearQuest 信息中心之中的“关于 Change Management Server”话题提供了对 CM 服务器的一般介绍。对该话题的链接可以通过本文的 参考资料 部分获得。

怎样设计测试场景

测试场景必须模拟实际生产环境之下所发生的情况。

Rational Performance Engineering 团队所设计的测试场景，可以通过 developerWorks 文章 IBM Rational ClearQuest Web Version 7.1 Performance Reports 来获得。在您创建它之前就可以评审这些性能测试。

测试性能之前很重要的一点是理解程序。团队通常会根据自己的经验，以及对其他人如何使用 ClearQuest Web 的猜测来设计测试场景。该方法通常不会反映实际的用例模型，您可以通过分析 ClearQuest Web IHS 日志文件，access.log 获得它。

• 在 7.0 版本之中，您可以使用 Microsoft Windows 操作系统，文件位于 C:\Program Files\Rational\Common\rwp\logs 之中
• 在 7.1 版本之中，文件位于 C:\Program Files\IBM\RationalSDLC\common\IHS\logs 处。

日志文件包含了访问 ClearQuest Web 的 IP，ClearQuest Web 所访问的日期和时间的信息，HTTP 访问方法（例如，GET 或者 POST），以及访问的 URL。

文件拥有以下的格式：

9.51.12.24 - - [14/Jul/2010:14:31:53 +0800]

"GET /cqweb/cqhelp.cq?action=welcomepage HTTP/1.1" 200 7604

假设每一个不同的 IP 地址都对应一个不同的末端用户，通常来说都是安全的。使用 Firefox 浏览器上的 Firebug 附件可以分析 ClearQuest Web HTTP 请求，并帮助您将 URL 映射至末端用户交易。您可以从本文的 参考资料 部分中得到 Firebug 附件下载地址的链接。按照下面的方式来使用 Firebug 附件：

1. 打开 Firebug。
2. 在 ClearQuest Web 中执行一次交易，查看 Firebug 之中相应的 HTTP，并记录请求的 URL。
3. 重复第 2 步，直到您得到感兴趣的所有交易，及 access.log 文件中所列出所有 URL 的信息。
4. 使用上述信息来将 URLs 映射至交易。这是很合理的，因为不同的交易通常拥有不同的 URL。但是，当多个交易共享相同的 URL 时，您可以将其组织为一个合并的交易。

在您获得关于用户，访问时间及交易的列表，您可以编写一个程序，以分析它并得到足够的信息，帮助设计测试场景并搜集数据，以便用作真实生产，例如下面的范例：

• 用户负载 有多少用户会在指定的时间内访问系统？在某天 24 小时内用户负载的变化情况如何？
• TPH（每小时内的交易） 在特定时期内，一个用户平均执行多少次交易（例如，在 2010 年 8 月 9 日这一天上午 9 点到晚上 10 点这段时间内）？
• 交易 什么是主交易呢？每一个主交易所占的比例是多少？对于一个合并交易来说，在您得到其百分比值之后，在设计测试交易百分比时，将百分比基于自己的经验分布给成员交易。

挑选峰值时间，分析相应的 access.log 文件，并得到该信息，这样您就可以设计更好的测试场景了。定期地重复该分析，以更好地理解产品环境，并指导您进行进一步的测试。

怎样创建测试脚本

在您设计测试场景之后，接下来的一步是将它们转化为测试脚本。这一步的重要性通常被低估。人们假设 Rational Performance Tester 之类的性能测试工具可以精确地生成一个测试脚本。不幸的是，有时这并不是真的。您可以使用接下来的指南来创建一个精确的测试脚本：

• 不要去记录一个交易。相反，您可以将每次交易记录两次，并单独地测试性能。例如，对于“Find record by ID”交易，您可以搜索记录 1，搜索记录 2，将它们做成两个交易，并单独的测试性能。因为是在 对ClearQuest Web 客户端上操作，所以交易会记录两次，它会在客户端和服务器端都进行缓存和预处理。因此，第一次发送的 HTTP 请求与第二次所发送的有所不同。
• 熟悉 Firebug 及 HTTP 请求，和感兴趣交易的响应。
• 检查测试工具所生成的测试脚本。对于每一次交易，将测试脚本与 Firebug 中实际看到的进行比较，以决定它们是否是一致的。另外，将 Firebug 输出与实际的性能进行比较。

一般情况下，HTTP 请求本身不会花很多时间，但是用户可以预期性能，因为大多数的时间会花在浏览器或者 JavaScript 上。

另一方面，有时 Firebug 会指示监测到许多正在进行之中的 HTTP 请求，但是用户会将性能想象地过好，因为背景中发生有请求，对用户经验不会产生影响。

• 测试您的脚本，以确认它是正确的。检查 ClearQuest Web 之中的错误日志文件 SystemErr.log，以确定没有错误信息。Windows 之中的日志文件默认条件下位于 C:\Program Files\IBM\RationalSDLC\common\CM\profiles\cmprofile\logs\server1\

怎样调试性能

在您对文本脚本满意之后，接下来的一步就是运行性能测试了。如果结果满足了需求，那么恭喜您！如果没有满足，那么您可以按照下面的步骤来调试性能：

1. 调试 ClearQuest 的使用。ClearQuest 是灵活的，对怎样操作查询或者 hook 代码所设置的限制很少。当然，反面就是这种灵活性可能会被滥用，而结果就是性能变慢。
2. 调试 CM 服务器及 WebSphere 服务器。
3. 调试 SQL 数据库。

调试 ClearQuest

这一部分包含了查询优化及方案优化。查询优化涉及到了怎样改进慢速查询的问题。方案优化涉及到了怎样改进与记录相关操作的性能。

查询优化

慢速ClearQuest 查询通常是由慢速的 SQL 语法造成的。一旦您意识到这一点，那么优化就成为直接的考虑了：优化 SQL 查询然后在 SQL 查询与 ClearQuest 查询语法之间进行转换。怎样执行 SQL 优化，您有很多资源可以参考，例如，Peter Gulutzan 所著的《SQL Performance Tuning 》。该书的链接可以从 本文的 参考资料 部分中获得。

按照下面的方法来查看 SQL 声明：

对于 ClearQuest 查询来说，在 Windows 上的 ClearQuest Eclipse 客户端或者 ClearQuest 客户端上得到生成的 SQL（注意 ClearQuest Web 上并不支持它）。

• 对于 Eclipse 客户，您可以选择查询，并从文本菜单之中选择 SQL > View SQL。
• 对于 Windows 上的 ClearQuest 客户端来说，您要确认菜单项 View > View SQL pane 被选中了。然后您可以运行或者编辑查询以显示查询的不同的编辑器，并点击 SQL editor。

如果 ClearQuest 查询包含了命令行，那么您必须执行查看声明的前述步骤：将原始的查询复制到临时的文件夹之中，并使用动态的查询来替代动态的筛选。然后使用上述方法中的一种来获得 SQL 声明。

在您获得 SQL 声明之后，您可以找到由下述问题造成的性能问题：

• ClearQuest 会对自己进行查询。在这种情况下，您可以调试一下查询。
• ClearQuest 查询没有能力生成足够的 SQL。在这种情况下，您可以将查询转化为 SQL，正如在帮助文件中指出的那样。

通常来说您并不需要优化 SQL 声明。大多数的问题可以通过在 ClearQuest 客户端中调试查询筛选定义来得到解决。慢速 SQL 通常是由 WHERE 语句不够，它对应于 ClearQuest 中查询筛选定义不够。为了解决这个问题，您可以系统地检查整个的筛选树：

1. 检查筛选执行计划。
2. 检查每一个查询筛选，包括它的字段名，操作者以及筛选值。
3. 考虑筛选操作是否可以有效地完成。如果不是，那么您可以试着将筛选转化为更加有效的替代品。

以下的建议可以帮助您避免一些常见的错误。

• 数据库索引对于查询性能来说十分关键。查询很慢，因为没有索引或者索引不足够。您要决定字段是否拥有索引，如果是的话，那么查询是否能够有效地使用索引。
• ClearQuest 为 ID，DBID，STATE，REFERENCE 及 REFERENCE_LIST 字段创建了一个索引，为拥有单独键值的字段也创建了一个索引。
• ClearQuest 并不会为 INT，DATE_TIME，SHORT_STRING，或者 MULTILINE_STRING 字段创建一个索引。因此，如果查询筛选字段是这种类型中的一个，而相关的表格很大，那么查询的速度会非常慢。为了改进查询的性能，那么您可以考虑手动为这些字段创建一个索引。
• 使用历史表格字段作为筛选（例如，history.action_name）。这是因为历史表格通常都是非常大的，而 ClearQuest 并不会为大多数的字段创建索引。并不推荐您手动创建一个索引，因为历史表格会频繁更新，而索引可能会损害更新的性能。但是，7.0.0.0 之后的版本之中ClearQuest 并不会为字段 entitydef_id 与 entity_dbid 创建合并的索引，如果您的数据库版本是在 7.0.0.0 之前，那么您应该按照 Indexing the History 表格中的指南进行操作，以手动创建索引。
• 使用筛选操作器 CONTAINS，因为 CONTAINS 操作器不会使用索引。

方案优化

对于大多数与记录相关的操作，缓慢的性能是由方案设计及 hook 代码不足造成的。

您可以得到怎样为性能设计方案的良好材料，例如 developerWorks 文章 IBM Rational ClearQuest 通用方案设计性能 以及使用 hook 的性能建议。本文不会在主要的内容上重复，但是会强调以下的内容：

• 限制对 of Recalculate choicelist 的使用
• 减小对调用 $session-> GetEntity 的使用
• 使用以下的格式来得到一个固定的字段值：$entity->GetFieldStringValue("project.leader.full_name")
• 不要构建一次查询以得到一个字段选择列表。而要使用以下的查询：$entity->GetFieldChoiceList("Owner")
• 使用 REFERENCE_LIST 字段。每次使用都会添加两个 SQL 查询。
• 避免使用 Field hooks
• 谨慎使用后-引用
• 确定附件表格拥有一个适当的索引。如果您的 ClearQuest 数据库是在 7.0.0.0 之前创建的，而默认条件下 Attachments 表格没有得到索引，您需要按照引用 Attachments 表格中支持文件索引的指南，来手动创建一个索引。

为了增加您对 ClearQuest 什么时候执行每种类型 hook 的理解，并帮助您评价 hook 代码，您可以查看信息中心来得到字段与操作的执行顺序。对该话题的链接可以从本文的 参考资料 部分中得到。

调试 CM 服务器与 WebSphere Server

ClearQuest Web 的技术文本 Change Management Server（CM 服务器）配置指南包含了重要的指南，以配置 CM 服务器优化性能。

有两个 CM Server 参数，maximumActiveServers 与 activeHttpSessionThreshold，对性能有着重要的影响。服务器所支持用户的最大数量，是由这两个参数值所设定的。设置一个您想要服务器支持的用户数量值，调整两个参数直到达到最佳响应时间为止。当您在调整

activeHttpSessionThreshold 时，您还有调整 serverWorkerThreadCount，一个好的开始就是让其保持相同，当每一个会话拥有进行中的任务时，一个线程可以为一个会话提供服务。

WebSphere 性能调试是一个很大的话题。WebSphere Application Performance 网址及 developerWorks 文章 案例研究：为性能调试 WebSphere Application Server V7 提供了有用的指南。

• JVM 存储大小。推荐您将存储大小的初始值及最大值增加到 1.5GB。
• 线程汇大小 。在一个客户环境之中，我们可以从默认值 200 开始，每次增加或减小 50，最终达到 Default 及 Web Container 线程汇的最大值 250，可以达到最佳性能。但是对您的环境来说，情况可能不同，推荐您按照 WebSphere 性能调试指南来操作，执行自己的性能测试，以得到适合具体环境的设定值。

调试数据库

正如上面所提到的那样，数据库索引对性能来说十分关键。ClearQuest 会为特定类型的字段创建一个索引，它应该涵盖大多数的用例。但是在边缘用例中，您可能想要手动创建索引，以便加速特定的操作。在您手动创建索引时要谨慎操作。记录您所做的每一次更改操作，并咨询 IBM 支持/服务。
为了分析与数据库相关的问题，您可以激活 ClearQuest 核心追踪功能，这样您就可以追踪慢速 SQL 声明了。在 Windows 中，设置以下的注册密钥以激活追踪功能：

[HKEY_USERS\.DEFAULT\Software\Rational Software\ClearQuest\Diagnostic]

"Trace"="SQL;DB_CONNECT;"

"Report"="MESSAGE_INFO=0x40B;DIAG_REPORT=0x01"

"Output"="c:\\trace.txt"

总结

本文介绍了性能测试及调试新 Rational ClearQuest Web 7.1 架构的系统性方法。对于测试，文中介绍了两个主要的阶段：怎样设计测试场景，以模拟生产阶段，以及怎样确定测试脚本反应了测试场景及用户预期的性能。对于调试，本文介绍了查询优化；方案优化；及 CM 服务器，WebSphere 及数据库调试的建议。许多性能问题是由 ClearQuest 使用不足造成的，因此可以按照最佳实践方式，以及本文中所介绍的调试方法和相关的资源来解决。但是，与调试指南类似，具体的环境可能有所区别，因此在使用之前您必须先进行确认。