ClearQuest性能调优—应用程序篇-UML软件工程组织-火龙果软件

UML软件工程组织

ClearQuest性能调优—应用程序篇

作者:going_paradise 来源:tianya

这篇文章实际上是一个读书笔记，为了锻炼自己的翻译能力，所以我把和Shcema设计时需要考虑的关键句子先用英文列出来，然后翻译在下面，最后结合自己工作中的体会有一个译者注，英文原文在附件里。要说明的是，本人以前为未做过类似翻译的工作，英文水平一般，所以在翻译过程中有些用词比较别扭和晦涩。请大家多包涵。促使我写这篇笔记的原因是，前段时间修改CQ应用程序并Upgrade到正式库后，本地用户反应性能有下降，但不是很明显，在可接受的范围之类。由于我们有异地开发，并且未使用IBM推荐的ClearQuest MultiSite和Web方式，性能的下降甚至是10倍级而无法忍受的。深刻体会ClearQuest Schema设计在性能方面的作用，但在网上这方面资料非常少，或者几乎没有，后找到的这篇英文资料可能很多人在设计中也未注意到，因为如果没有异地开发性能下降的教训，只做本地开发，数据量还不大的情况下，一般是不会考虑到性能的。根据这篇文档，我重新修改了设计，性能立刻就提升了。

Rational ClearQuest Performance Optimization

Regardless of how you will be deploying Rational ClearQuest– Windows or Unix clients, a Web Server, or a combination of several interfaces –your level of application performance will depend largely on how you address the following three key areas:
　　1. Schema Design Considerations
　　2. Server Configuration (Database and IIS Servers)
　　3. Network Configuration
　　We’ll discuss each of these in the following sections。

翻译：无论你怎么部署ClearQuest----Windows平台客户端，Unix平台客户端，还是Web服务器，或者是它们的混合。CQ 应用程序性能水平很大程度上依赖于你怎么实现以下三个关键的部分。

1、 Schema设计考虑；
　2、服务器配置（数据库和IIS服务器）
　3、网络架构

我们会在下面的章节里讨论这三点。
　　
　译者注：CQ应用程序从三个方面考虑，本篇笔记只翻译和关注第一点Schema设计需考虑到的地方。由于在工作中主要我们现在主要在Windows平台Clients端使用，所以主要关注的是与这部分有关的性能调优，对使用Web的应用程序未考虑。对于此详细可查看：http://members.cox.net/ejostrander/clearteam/cq_howto.html#MISC14

Schema Design Considerations

This is probably the one area of your Rational ClearQuest deployment where you have the most control over how the application is going to perform. While Rational ClearQuest is a flexible and configurable change management system, it is not intended to be a complete program development environment. It is designed for customization of the “out of the box” schemas, not for complete re-implementation of the underlying database application. If you find yourself writing thousands of lines of hook code in ClearQuest, you should probably look to simplify your business use cases instead of trying to capture and implement these complex rules in your hooks. The result will be a system that is much easier for you to deploy and maintain, and much more usable for your team members who are using the application to track defects and change requests. As a schema designer, you will have many choices on how you implement the desired functionality in your schema. In most cases, there is more than one way to achieve a particular result, and understanding the performance implications of using various constructs in Rational ClearQuest can help you make good decisions that will provide your users with the functionality they need with minimal impact to overall performance.

翻译：在部署CQ时，Shcema设计的考虑是你最可能提高应用程序的性能地方。由于CQ是一个灵活和可配置的变更管理系统，而不是一个完整的程序开发环境。它的设计是基于基本的Schema的定制，而非一个数据库系统的完全实现。如果你发现你在一个Hook里写了几千行代码，你可能需要重新检查并简化你的业务用例，而非试图在HOOk去寻找和实现这些复杂的规则。这样做的结果是，CQ是一个更容易部署和维护的系统，并且使用这个系统作为bug追踪和变更需求的团队成员来说更容易使用。作为一个Schema设计者，要在你的Schema里实现一个特定的功能你有很多选择。在很多情况下，有不只一种方法可以实现一个特定的结果。理解在Rathional ClearQuest里使用不同的程序构造的性能含义，可以帮助你在提供给用户所需要的功能和性能的最小影响之间做出更好的选择和判断。

译者注：这段文字是在做Schema设计时的一个大纲性质的论述，CQ不是一个完全的开发环境，它不过提供了一个环境可以让我们进行二次开发，我把它理解为一个轻量级的开发环境。在需要实现的功能需要大量的代码时，我们首先要做的是考虑是不是我们的业务规则有问题，流程是否合理。然后在做设计时，要考虑性能和需实现的功能之间的平衡，在这篇文章中，多处使用了“Trade-Off”这个词，翻译过来就是两难选择，或者用通俗点话说就是两害相权取其轻。有时候为了性能考虑，我们不得不牺牲一些功能。在下面的文字中，将会看见我为了性能考虑，牺牲了一些代码的简洁和牺牲了一些原本已经实现的功能。

Rational ClearQuest Hooks – Performance Considerations

Regardless of your chosen scripting language, keep in mind that when a user logs in to Rational ClearQuest – whether it be through a native Windows or Unix client or through the web interface – all hook code defined in the schema is loaded into memory on the CQ client (or CQWeb Server). More hook code results in longer login times and more memory consumption.

翻译：

无论你选择什么(VB,Perl,译者注)作为的脚本语言，都需要记住，当用户登录时，不管是通过Windows或Unix平台的客户端还是通过Web访问，所有在Shema中定义的Hook代码都会加载到CQ客户端（或CQ Web服务端），很多Hook 代码会引起登录需要更多的时间和更多的内存消耗。

译者注：这就是上面说的，如果要实现一个功能需要几千行代码的话，应该重新考虑业务用例。太多的代码会是登录时时间加长，并且消耗内存。

Also, ALL Record Scripts (for the current Record Type) and ALL Global Scripts are passed to the interpreter and compiled – EACH AND EVERY TIME an “action” is performed or a base action hook executes. It doesn’t matter if the executing hook actually uses any of the Record Scripts or Global Scripts – they are still passed to the interpreter. This can have performance implications, particularly if your schema contains significant amounts of code in Record Scripts and/or Global scripts. To minimize the amount of code sent to the interpreter, consider using PERL modules or VBScript COM objects – which can be loaded on an “as-needed” basis at execution time – to encapsulate your global scripts.

翻译：

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

译者注：这就是我在<<在CQ HOOK里发送带附件的邮件>>里提到的，除非有必要，不要有冲动把有些函数写全局函数，在我以前的开发经验中，对于一些处理字符串或者数组的功能，如返回一个字符串里从左到右搜索某个子串左边部分，右边部分，从右到左搜索某个子串左边部分，右边部分。数组转化为字符串，判断某个元素是否属于某个数组等功能。我习惯于把这些写成一个个的函数在其他程序中调用，但是由于CQ的这个限制，很多时候只有牺牲代码的简洁，在CQ里写代码，没有办法把代码写得象诗，只能写得象记叙文。由于我们一定开发比较多，我写CQ的Global Scripts函数时的原则是，如果某个功能至少在其他代码里有5处的调用，我才抽出为一个全局函数。说实在的，这一点让人很郁闷。上面这段说用VBscript Com对象，问题是很多常用的功能还需要自己写成函数的。

Avoid using “AdminSession” to access data from the schema repository. User information is stored in the user database, so there is no need to go to the schema repository for data such as the user’s full name, etc. If you must retrieve data from the schema repository, store it in a Session Variable for reuse. (see example of using session variables below)

翻译：避免使用“AdminSession”对象从Schema repository库里取得数据，用户信息已经存到用户数据库，所以不需要从Schema repository数据库取得用户全名等信息。如果你真的需要从Schema repository数据库取数据，把这个数据存到Session变量里以遍重复使用。（请看下面的使用Session变量的例）

译者注：在以前的Hook中，我从来没有使用过AdminSession对象取数据，关于为什么不要使用AdminSession取数据，在我这篇文章开头提到那个网站上，Eric J. ostrander有论述：“If an AdminSession is started within a hook, CQ must load all the DLL's and assorted information into that session, which takes just as long as if somebody was starting the CQ Client from start”，从这里可以看出，如果使用了AdminSession对象，CQ需要加载所有的Dll文件和分配各种信息到Session里，需要花费和登录一样的时间。

Avoid using “Recalculate Choice List” in your field properties. Doing so will force either a round-trip to the database or a hook script to run every time any field in the record is changed during an edit. Instead, write a “VALUE_CHANGED” hook in the “parent” field to force an update on the “child” choicelist values using the “InvalidateFieldChoiceList” and “SetFieldChoiceList” methods.

翻译：在字段属性上避免使用Recalculate Choice List。这样做会产生这样的结果，当一条记录在编辑时，当任何一个字段的值改变时都会读取数据库一个来回，并且运行hook脚本。替代的解决方案是，在“父亲”字段的“VALUE_CHANGED”hook里用“InvalidateFieldChoiceList” and “SetFieldChoiceList” methods方法来更新其子字段的内容。

译者注：这是最需要注意的地方，实际上，我此次发生的性能下降问题主要就是这个原因引起，在Basic实现的Choice List属性上，由于对Recalculate Choice List性质了解不深，导致异地使用CQ慢了10个数量级，本地也有性能影响。在CQ中用Hook 实现Choice List时，应严格避免使用这个属性。这个属性的作用，举例说明，我的一个记录类型上有两个字段“项目”和“模块”，其中“模块”列表依赖于用户在填写时选择的项目的值。这个时候钩上这个属性很容易就实现了，但这个是以性能下降为代价的。IBM网站上有替代的选择是Dependent Choice Lists，在父字段的Value Changed 的Hook里写代码来实现。

Static/Dynamic Choice Lists should have <100 entries. This is because of cache limits in the Rational ClearQuest client. If you need more than 100 choices, use a REFERENCE_LIST.

翻译：静态或者动态的Choice Lists的条目应该小于100个。这是因为客户端的内存限制，如果你需要100个以上的Choices，用REFERENCE_LIST来实现。

译者注：在我写应用程序过程中，没有使用过100个以上条目的Choice Lists，倒不是考虑到性能，而是如果有100个条目，估计整个CQ客户端界面都显示不完，应该很少有人这么做。但是，知道这个会影响性能也是必要的，这样以后我们在考虑功能实现时，可以更关注于性能。

Limit number of REFERENCE or REFERENCE_LIST fields displayed on a form. Rational ClearQuest must perform a “join” of all record types referenced by a form in order to render that form