一、概要
    这本白皮书的目的是为了巩固一些关于ClearQuest性能方面的有用信息，从而形成一些通用资源。其中包含了一些建议和超文本链接的详细资料以及Rational ClearQuest管理员和schema设计师探索出Rational ClearQuest性能优化的经验。初次担当schema设计师的人可以从RDN ClearQuest Hooks Index获取一些很好的例子，同时也可以从这篇文章里得到有关hook事例来帮助您避免一些性能方面的问题。

二、Rational ClearQuest 性能优化
    无论你怎么部署ClearQuest----Windows平台客户端，Unix平台客户端，还是Web服务器，或者是它们的混合。CQ 应用程序性能水平很大程度上依赖于你怎么实现以下三个关键的部分：
1) Schema设计考虑；
2) 服务器配置（数据库和IIS服务器）
3) 网络架构我们将分别讨论下列部分。
我们会在下面的章节里讨论这三点。

三、schema设计注意事项
    在部署CQ时，Shcema设计的考虑是你最可能提高应用程序的性能地方。由于CQ是一个灵活和可配置的变更管理系统，而不是一个完整的程序开发环境。它的设计是基于基本的Schema的定制，而非一个数据库系统的完全实现。如果你发现你在一个Hook里写了几千行代码，你可能需要重新检查并简化你的业务用例，而非试图在HOOk去寻找和实现这些复杂的规则。这样做的结果是，CQ是一个更容易部署和维护的系统，并且使用这个系统作为bug追踪和变更需求的团队成员来说更容易使用。作为一个Schema设计者，要在你的Schema里实现一个特定的功能你有很多选择。在很多情况下，有不只一种方法可以实现一个特定的结果。理解在Rathional ClearQuest里使用不同的程序构造的性能含义，可以帮助你在提供给用户所需要的功能和性能的最小影响之间做出更好的选择和判断。
 
     Rational ClearQuest在Rational ClearQuest schema设计师依据他/她的实施情况提供了几种“out of the box”schemas，虽然许多schema设计师的要求主要是满足提供的功能在这些schema，另一些更复杂的需求，如：
1) 多级父/子关系的变更请求和/或其他记录
2) 需要跟踪整个历史上所有变更（代理机构有时需要这个）
3) 基于角色的过程控制需要广泛的hook脚本
4) 复杂的需求变更通知，形成许多电子邮件规则
相关字段，为一个字段有效的选择清单列出值， 取决于所选的一个或多个其他字段的值。
Rational ClearQuest的实施必须满足以上的这些要求，更进一步的是你需要优化性能的环境。

四、Rational ClearQuest Hooks—性能注意事项
    特别需要注意的是在schema中使用hook代码——特别是如果你的hook在Perl中执行，而不在VBScript。你通常可以选择是否使用Perl或VBScript在Rational ClearQuest hooks中，这是有限制的，不过这可能迫使你使用这个或另一个。例如，如果你的环境需要支持用户本地的Unix客户端的Rational ClearQuest，那么你必须撰写你的hooks在Perl中，因为VBScript脚本不支持Unix环境。 无论你选择什么(VB，Perl，译者注)作为的脚本语言，都需要记住，当用户登录时，不管是通过Windows或Unix平台的客户端还是通过Web访问，所有在Shema中定义的Hook代码都会加载到CQ客户端（或CQ Web服务端），很多Hook 代码会引起登录需要更多的时间和更多的内存消耗。

    同时，当每次执行“Action”或者一个Base Action Hook被执行时，所有的记录脚本（当前的记录类型）和所有全局脚本都会传给编译器和进行编译。无论这些执行的Hook是否使用这些记录脚本或全局脚本，他们都会传给编译器。这个情况和性能有很大的关系，特别是如果你的Schema里包含较多重要的记录脚本或者全局脚本时。为了使传给编译器的代码数量最小，考虑使用Perl模块或者VBSrcipt Com对象——他们能够在执行时按需加载，从而达到压缩全局脚本的目的。

五、使用Perl的附加性能影响
    如果你计划提供用户通过CQWeb访问您的Rational ClearQuest，重要的是要记录CQWeb单线程perl代码的执行情况。这将限制在Rational ClearQuest hooks中使用Perl作为一种脚本语言执行CQWeb的可扩展性。除非您的部署还包括——或很可能包括——本地的Unix/L inux客户端，建议使用VBScript而不是用perl部署CQWeb，特别是如果您执行需要大量hook 代码。

六、附加schema设计指南
     其余的本节提到的其他一些资源，这些资源提供了在您的schema中使用某些Rational ClearQuest架构产生性能影响的详细资料。在性能和功能之间你必须作出取舍，以及你最好作为一个schema设计师理解这些权衡，就越有可能部署一个成功的Rational ClearQuest应用程序。

1. 避免使用“ AdminSession ”从schema repository获得的数据。
    用户信息存储在用户数据库，因此没有必要在schema repository存放的数据，如用户的全名，等等，如果你必须从schema repository中重新找到数据，把它存储在会话变量以便重用。（看下列使用会话变量事例）
2. 在字段属性上避免使用Recalculate Choice List。
    这样做会产生这样的结果，当一条记录在编辑时，当任何一个字段的值改变时都会读取数据库一个来回，并且运行hook脚本。替代的解决方案是，在“父亲”字段的“VALUE_CHANGED”hook里用“InvalidateFieldChoiceList” and “SetFieldChoiceList” methods方法来更新其子字段的内容。
3. 静态或者动态的Choice Lists的条目应该小于100个。
    这是因为客户端的内存限制，如果你需要100个以上的Choices，用REFERENCE_LIST来实现。
4. 限制在一个表单上REFERENCE 或REFERENCE_LIST字段的数量。
    在显示时这些关联的记录时，Rathional ClearQuest需要执行一个“加入”所有被这个表单关联的记录类型。Multi_Table的加入是耗时的操作，当一个表单上REFERENCE 或者REFERENCE_LIST的数量增加时，时间的消耗会急剧增加。首要的规则是在一个表单上不要有超过10个这样的字段。

5. 避免使用FIELD_VALIDATION hook。
    当执行一个Action时，任何域值的改变都会导致Field validation hooks执行一次。（它同时也增加了在登录时加载到内存的代码数量），替代的解决方法是，在ACTION_VALIDATION hook里检查每一个域值的合法性，这样只有用户点“Apply”进行提交修改时才执行一次。

6. 尽量执行hook代码减少数据库查询中。
    只要有可能，应该把最常用的查询值记录到一个Session 变量里。当在这个Session期间，每次Hook执行时只需要去读取这个Sesssion变量的值而不是重新去执行查询。这样做只是对那些比较静态的数据来说，如用户信息，EntityType 数据或者其他。如果你用一个Session变量存储一个查询的返回数据如“当前用户的所有打开的bug”，你可能会以为这个Session变量持续地使用导致原来的数据过期的风险。请看下面使用Session变量来避免一个查询的例子：    

7. 避免在查询中返回MULTILINE_TEXT字段。
    没有multiline text字段，CQ会一次从数据库中批量选择250行。因此，一个返回N条记录的查询只需要N/250次客户端到数据库之间的逻辑往返查询。如果有multiline text字段，CQ会取一条记录的所有非multiline text字段为一行，然后取multiline text字段为一行。然后CQ用同样的方式再取下一条记录。因此，一个返回N行包含M个multiline text字段记录的查询需要(1+M)*N次逻辑往返查询。注意：关于这个问题的一个补丁包计划在V2003.06.00解决，在安装这个补丁包之前建议不要使用返回multiline text字段的查询。

8. 谨慎的使用电子邮件规则。
    每一个邮件规则都包括一个过滤，每一个过滤和一个查询相联系。每一次邮件规则运行的时候，关联的查询也会执行。每一个Action的时候，邮件规则开始加载并开始运行。作为邮件规则的一个替代选择，可以使用Notification Hooks（在那里需要写代码来实现发送邮件），这样就可以在相应Action的时候才触发这个Hook。试着最小化和合并邮件规则以减少查询代码执行的数量。这意味着要给一个更广泛的用户范围发一封未定义的邮件。不过从性能上考虑是值得的。

9. 想去某个字段的值的时候不要取出完整的记录。
    从CQ中取出一个完整的记录是很费时的操作。如果你只需要从一个记录或者记录集合里取一个或者两个字段的值，使用一个只查出这些字段的值作为结果的查询比取出整个记录或者循环查找记录集合取得想要的字段更有效率。 同样的，你可以取的一个记录里关联字段的值而不需要完整地取出整个记录。如：假设当前的Entity有一个字段叫“Project”，这个字段REFERENCE到其他包含一个字段叫“name”的记录类型，用如下的代码，你可以得到关联的字段：
    my $projname = $entity->GetFieldValue("Project.Name")->GetValue();
这样取值会比下面的代码更有效率：
    my $project = $entity->GetFieldValue(“Project”)->GetValue();
    my $projname = $project->GetFieldValue(“Name”)->GetValue();
 

七、服务器配置
首先，这是至关重要的，你分别配置数据库服务器和IIS服务器（如果您使用的是CQWeb ）在单独的机器上。这不仅将提高性能的分配负荷，而且还大大改善了Rational ClearQuest环境的稳定性。

八、数据库服务器
    不管后端数据库供应商为你的Rational ClearQuest implementation选择什么配置，这有一些普通的配置任务有助于确保达到最高的性能。需要专门的数据库管理员定期调整和维护企业级的数据库，这对Rational ClearQuest 应用程序长期性能和可扩展性是至关重要的。
    ClearQuest创建indexes 在ID字段的全状态记录类型和主要关键字段的无状态记录下。这些indexes不能被删除或被篡改否则数据库系统的许多正常操作将被损害。其中一个关键点提高Rational ClearQuest数据库性能的是，在表单上创建更多的indexes易于访问。知道在何处以及如何运用indexes要求后端数据库使用数据库管理员级别的知识，并理解什么是有帮助的，什么是不能基于特殊查询所执行的。虽然是一项很重要的任务，这也将对数据库管理员在数据库中重复执行SQL查询极为有益，并使构建indexes进行优化设计的速度来存取所需要的数据。由于不同的schemas和不同的使用模式，需要不同的indexes来优化性能，它远远超出了这个范围，这本白皮书并没有提供如何创建将有利于所有的Rational ClearQuest implementationsindexes的具体细节。请参阅以下解决方案的例子建立indexes的历史和附件表中的Rational ClearQuest数据库：
? Solution ID: 25610 – Create an INDEX on the History Table
? Solution ID: 140585615 – Create an INDEX on the Attachments Table
需要周期性的维护indexes -他们通过数据库升级被覆盖，例如-因此请务必文档化的程序。 同样，诊断Rational ClearQuest性能问题时，在ODBC处开启SQL跟踪是很常见的。然而，为了确保最高的性能，请务必在你的数据库是“活”的时，SQL跟踪没有启动：
? Solution ID: 129591114 – WINDOWS: SQL tracing cause any problems? How do I start or stop SQL tracing?
? Oracle-–特别推荐
? Solution ID: 18912 – Oracle Patch information for Rational ClearQuest Web performance/reliability issues
（Oracle针对Rational ClearQuest Web性能/可靠性发行的补丁信息）
? 基于表的大小和已有indexes，分析数据库优化性能
a. 在schema和user databases（用户数据库）两者上都运用。
b. 优化模型应该可能被设置成CHOOSE（可选）。
c. 优化模型是动态参数， 它可以被设置成任意时间执行：
    ALTER SESSION SET OPTIMIZER_MODE='CHOOSE'
d. 举例：
sqlplus sys/<Password>@<TNS-Alias>
SQL> exec DBMS_UTILITY.ANALYZE_SCHEMA ('<schema-name1>','COMPUTE');
SQL> exec DBMS_UTILITY.ANALYZE_SCHEMA

应该定期清除Oracle 档案日志
? SQL Server –特别推荐
SQL Server 配置技术资料
a.（如何创建空的SQL server7/2000数据库）
Solution ID: 13900 – WINDOWS: How to create an empty SQL_SERVER 7/2000 database
b.（SQL Server安装中的性能调整）
Solution ID: 16187 – WINDOWS: SQL Server Performance Tuning during setup
c.（SQL Server性能调整的硬件瓶颈）
Solution ID: 16188 – WINDOWS: SQL Server Performance Tuning Hardware Bottlenecks
d.（在Windows NT4.0上的SQL Server性能调整）

九、IIS Web 服务器
1．确保根据Rational ClearQuest Installation Guide（Rational ClearQuest安装指南） 中的说明来配置IIS。
2．确保用户在关闭浏览器之前退出并且/或者设置登录超时（Login Timeout ）为一个较短时期：
? 用超级用户权限，从CQWeb的操作菜单中选择“Edit Web Settings”
? 改变超时（Timeout）为适当值，-你不想让用户离开工作仅有几分钟就丢失所编辑的内容……
3．定期重启IIS Web 发布服务(由于inetinfo.exe内存泄漏)
4．定期删除“<RATIONAL CLEARQUEST_HOME>/WWW/cache” 文件夹中的文件 。删除readme.htm以外的所有文件。
5．定期删除Windows事件管理器中的条目。
打开“控制面板->管理工具->事件管理器”
选择“应用”日志，点击“执行->清除所有事件”

十、网络配置
    为了理解在Rational ClearQuest环境中网络配置的重要性，需要理解下面Rational ClearQuest部署的架构（如图 a）、以及发生在不同组件间的通信过程。 这里的关键是IIS Web 服务器（IIS Web Server）和每个通过ODBC与数据库通信的Rational ClearQuest的本地客户机。这个协议 很“肥胖”，它不适用于广域网（Wide Area Network ）通信。如果你正使用CQWeb，你的IIS Web 服务器和你的数据库服务器（database）也应该放在相同的子网中，用高速连接更佳。如果你正用本地CQ客户机取代或增加到你的IIS Web 服务器，这些客户机也需要与数据库服务器尽可能快的进行通信。因此，重要的一点是，在你的Rational ClearQuest客户机与数据库服务器之间，要让“hops” （跳数）最小化。

    
十一、诊断软件性能问题
     Rational CleaQuest 是商业化的今天可获得的最为灵活、最易于配置的缺陷和变更跟踪产品之一，但伴随它的强大，它具有的功能产生好与坏同样可能的结果。一种通常的结果是糟糕的性能表现。如果你为了一个无谓的操作--比如调用一个动作或提交变更(查询所有的记录并生成冗长报告)正历经一个数秒钟的延迟，你接下来可以查看一下这个延迟是否是由于客户端进程(CQ核心进程或者你十一、诊断软件性能问题
Rational CleaQuest 是商业化的今天可获得的最为灵活、最易于配置的缺陷和变更跟踪产品之一，但伴随它的强大，它具有的功能产生好与坏同样可能的结果。一种通常的结果是糟糕的性能表现。如果你为了一个无谓的操作--比如调用一个动作或提交变更(查询所有的记录并生成冗长报告)正历经一个数秒钟的延迟，你接下来可以查看一下这个延迟是否是由于客户端进程(CQ核心进程或者你的hook代码)、数据库服务器进程、或者网络延迟引起的。
 
    为了确定在你的CQ环境中时间是在哪里被消耗掉的，使用跟踪机制(下面讨论)，选择API和SQL(在1分钟内)，并包括时间戳。通过日志信息，你应该能够确定花费大块时间的地方，从而集中改进它。如果是在SQL中，查一下数据库给你的响应时间，一些SQL响应时间不好的原因包括：
? 不充足的网络带宽/争夺
? 长距离(不推荐WAN操作或不支持WAN操作)
? 域划分(SQL客户端与服务器之间的网络hops (跳数)量减到最少)
? 不充足的数据库平台硬件
? 不合适的indexes数据库表(详细历史)
    如果跟踪涉及到了某些hooks，你应该在hooks提供的功能和与它冲突的表现效果之间权衡取舍。当显示一个表单的时候，如果你看到数据库服务器大量的交易和(或)过多的客户机进程时间，你应该再仔细看你对Reference型字段的使用，根据选择列表和/或你对“重新计算选择列表”的使用来看一下是否你能使你的执行更有效-紧记本页前面提出的指导原则。

    举个例子，有几种方式可实现Dependent Choice Lists (依赖选择表)-从硬编码选择列表hooks到在stateless records一层的依赖。这些方法中的每一个都有它们各自的或优或劣的功能。详细见：“Implementing Dependent Choice Lists in Rational ClearQuest” 为了有助于你的调试，Session 对象支持一种带有字符串变量的名为“OutputDebugSreing”的方法。在Rational ClearQuest安装目录里，有一个dbwin32就是这个方法的应用。当dbwin32激活时，它将显示所有由OutputDebugSreing生成的信息。在Windows，Uinx 和Web(它作为Windows管理员运行在Web服务器中)上，从VB、Perl hooks 和外部脚本得来的这个信息是可用的。在你的hooks中运行dbwin32并增加调用OutputDebugSreing的策略以提供足够的调试能力。当dbwin32没有激活时，信息只进入比特斗(你作为管理员组的成员运行ClearQuest时，它记录在Windows2000中，否则，输出不会被显示出来。

    除此之外，有一个非常重要的跟踪特征，就是允许用户监视一组活动，比如数据交换，License(许可证)交换，API调用，email处理等等。这些跟踪在注册表(在[HKEY_CURRENT_USER\Software\Rational Software\RationalClearQuest\Diagnostic]中)或环境变量中可进行控制。下面举例说明注册表中有关项的设置、以及各项的所有通用设置和定义（每个项及其值都是举例）。 表见下页。
     

相当于使用下列环境变量，并且支持上述所有相同选项。在这个例子中使用了EVs和 Registry keys，优先取得EVs。

十二、附加资源
1) RUC 2001 Presentations
? CM24: Scaling Rational ClearQuest Web Servers (Hahn)
? CMA15: X-treme Rational ClearQuest (Exum)
2) RUC 2002 Presentations
? SCM13: Rational ClearQuest Performance Tuning (Kamath)
? SCMA12: X-treme Rational ClearQuest: Tips and Tricks (Mellott， McEwen)
3) Rational Developer Network
? Rational ClearQuest Customization Best Practices (Exum)
? Troubleshooting Rational ClearQuest – Problems You May Encounter (Rational)
4) Tech Notes / Solutions
    Search using keywords such as “Rational ClearQuest” and “performance” at: www.ibm.com/software/rational/support/
 IBM Software Group Dual Headquarters: Rational Software 18880 Homestead Road Cupertino， CA 95014 Tel: (408) 863-9900 Rational Software 20 Maguire Road Lexington， MA 02421 Tel: (781) 676-2400 Toll-free: (800) 728-1212 E-mail: info@rational.com Web: www.rational.com International Locations: www.rational.com/worldwide Rational and the Rational logo， among others， are trademarks or registered trademarks of Rational Software Corporation in the United States and/or other countries. References to other companies and their products use trademarks owned by the respective companies and are for reference purposes only. Copyright 2003 IBM， Rational Software Corporation Subject to change without notice. All rights reserved.