本文探讨了IBM Rational Requirements Composer Version 2.0服务器的性能与可评价性，包括不同配置与拓扑结构对性能的影响，以及如何优化服务器配置。
性能与可评价性在服务器基础的环境中具体十分重大的意义。取决于环境的复杂性，性能可以对软件的有效性造成或大或小的影响。IBM® Rational® Requirements Composer Version 2.0 服务器由一些一起工作以组成工具末端的模块组成。2.0 版本服务器构件可以用不同的拓扑结构和配置创建，这些结构和配置会影响到性能与可评价性。
因为我们已经过了初始的发布阶段，对该测试的主要关注点是服务器的性能及其潜在的基础结构。本文描述了服务器的具体内容，并解释了可以影响性能的各种服务器配置与拓扑结构。我们还描述了在不同的范围和结构下用于记录性能评价和可评价性工具的技术，并研究了测试的结果。
我们谈到了通过/比较不同的拓扑结构、数据库及 Web 程序服务器的发现，并考虑了用户数量及服务器资源的效果。另外，我们解释了怎样在您自己的环境中重现测试创建工作以完成您自己的性能测试。最后，我们为优化 Rational Requirements Composer 服务器性能的检查和规定提供了一些建议。
本文中的信息是分布式的 AS IS。这些信息的使用或者这些技术的实现是客户的责任，并取决于客户评价及集成到操作性环境的能力。因为 IBM 可能会评审每一项以追求特定方案的精确性，所以不能保证在其他的地方获得相同的或者相似的结果。客户想要在他们自己的环境中采用这些技术以完成自己的任务。该版本所有对外部 Web 站点的指针只是方便使用，而不是作为这些 Web 站点的认证。该文件中包含的所有性能数据都在一个受控制的环境中决定，因此，在其他操作环境中可能获得的结果也许会发生显著的变化。该文件的用户应该为指定的环境确认可应用的数据。
双边环境：一个程序服务器的服务器，一个数据库服务器的服务器
IBM® DB2® 或者 Oracle
IBM® WebSphere® Application Server 6.0 版本
最低机器规格
程序服务器
- Quad core 2.8 GHz CPU 及 8 GB 的 RAM
- 硬盘：高性能 SAS 硬盘、RAID、SAN 或者 NAS 直接联系的硬盘子系统
数据库服务器
- Dual core 2.9 GHz CPU 以及 4 GB 的 RAM
- 硬盘：高性能 SAS 硬盘、RAID、SAN 或者 NAS 直接联系的硬盘子系统
主要的性能瓶颈是程序服务器机器，它在不同的运行负荷下运行不同的测试。所以最好将一个双边的环境与寄主在程序服务器上的高品质机器一起使用。在我们的测试之中，IBM DB2 与 Oracle 数据库相似地处理用户负荷。因此，使用您和您的客户最愿意使用的数据库软件。我们还发现了对于不同的用户负荷，程序服务器的性能也是相似的。因为 Rational Requirements Composer 管理员的企业需要（安全性与管理情况），以及可定制性能调试的特性，所以我们更喜欢 WebSphere 服务器。
注意：
我们使用 IBM WebSphere Application Server 的一般配置而不进行额外的调试。
Rational Requirements Composer 服务器创建、处理并存储了 Rational Requirements Composer 客户端所使用的需求资源，并提供了查询和搜索这些数据的机理。它还为创建、管理和获得文件夹、标记、评论、链接及项目快照提供了特定的服务。
还有其他的一些部件组成了服务器。在核心，Rational Requirements Composer 服务器是运行一系列程序的程序服务器。其中主要有两个程序：一个 Requirements Composer 服务器程序一个 IBM® Jazz® Foundation Server 程序。还有一个额外的程序，它将 Rational Requirements Composer 资源生成 Web 上的可浏览图形。
图 1. Rational Requirements Composer 概述
Rational Requirements Composer 服务器由一个或者多个 Java™ Enterprise Edition （JEE）Web 服务器组成。Rational Requirements Composer 服务器能够同时支持 IBM WebSphere Application Server 与 Apache Tomcat。Jazz 技术平台与 Rational Requirements Composer 服务器程序都是安装并运行在 Web 服务器上的 Web 模块。程序可以根据拓扑结构来运行两个独立的 Web 服务器。在本文的稍后部分中，将会涉及到每一个程序服务器的性能。
Jazz 与 Jazz Foundation Services
Jazz 储存库构件处理了所有存储的 Rational Requirements Composer 工件与信息。Jazz Foundation Services 是一系列用于处理用户及项目管理、安全、协作、查询及其他跨工具功能的功能。
储存库末端是一个相关的数据库，它用于储存所有的服务器资源与工件。Jazz Foundation Services 可以从 XML 及 Resources Description Framework（RDF）文件然后从索引的信息中获得结构化的数据，这样就可以更轻松地获取和查询这些属性。另外，Jazz Foundation Services 使用一个单独的文本索引来在不同的资源间搜索全文本（通过 Apache Lucene）。
为了操作或者查询数据，服务器端的请求被转化为 SPARQL Query Language 声明然后在数据库上运行。
Rational Requirements Composer 服务器程序
除了 Jazz 技术平台提供的核心功能，特定需求的功能需要在服务器上进行处理。Jazz Foundation Services 提供了一种机理以使用前端的程序，它是一个包含程序和演示逻辑并使用 Jazz Foundation Services 以存储、查询和安全检查的服务器端的网络程序。Rational Requirements Composer 服务器是一种在 Java EE服务器上运行的前端网络程序，它与 Jazz Web 程序是隔开的。
除了提供特定需求的功能，前端程序机理使得 Rational Requirements Composer 服务器能够使用特定需求域战略来提高性能。这个在 Jazz Foundation Services 提供的标准缓存之外。
Rational Requirements Composer 网络程序
Rational Requirements Composer 服务器包含了允许从网络浏览器访问 Rational Requirements Composer 的功能。在服务器上运行的额外网络程序用于处理将 Rational Requirements Composer 资源转化为网页缩略图。
一个关系数据库用于测试资源的持续性。我们更想在 IBM Rational Requirements Composer 2.0 支持的两个企业数据库上执行我们的测试：DB2 和 Oracle。我们的测试关注涉及到大量用户（在我们的测试中我们并没有使用 Derby 数据库）的企业场景。Microsoft® SQL Server 并没有进行测试，因为它并不是运行测试期间支持的操作系统的一部分。
用于评价性能与可评价性的技术与工具
注意本文中讨论的数据，是在 Rational Requirements Composer 服务器上运行模拟用户的结果。实际的客户经验可能会与之不同，这取决于客户所在的环境与使用情况。
IBM® Rational® Performance Tester 用于模拟和评价 Rational Requirements Composer 客户端/服务器交流。测试环境得以创建以处理那些与 Rational Requirements Composer 服务器相交流的 500 个虚拟用户。
图 2. Rational Performance Tester 环境
Rational Performance Tester 主机
主机运行 Rational Performance Tester 工作台并为分配用户负荷和收集性能数据负责。这些是机器规格：
- Lenovo **，Microsoft® Windows Server 2003 Enterprise Edition，SP2
- 双核 CPU 2.66 GHz，4 GB RAM
主机会在五个 Rational 测试代理机器之间平均地分配用户负荷。
Rational Performance Tester 代理机器
环境包含了五个 Rational Performance Tester 代理机器。每一个机器都接受一系列用户发出的请求，并向 Rational Requirements Composer 服务器发送请求。机器会记录响应时间和结果，然后向主机发送数据。每一个代理主机都有下列的规格：
- Lenovo **，Microsoft Windows Server 2003 Enterprise Edition，SP2
- Dual CPU 2.66 GHz, 4 GB RAM
对于测试数据，为了让代理机器不至成为性能的瓶颈，每一个代理机器都会模拟不超过 100 个用户。
有两个每一个用户都要执行的用例：一个 Author 用例以及一个 Reviewer 用例。每一个用户都会执行一个测试用例然后等待 120 秒再去重复用例。在用例的私人操作之间没有添加的额外“思考时间”。资源上的所有操作都是随机的。基于真实的客户使用，我们的测试场景由 Authors 对 Reviewers 按照 1:4 的比例组成。一个典型的测试场景中有 500 个用户，产生 705 个资源，更新 2,287 个资源，并且每小时创建 5,876 个评论。同时伴随着其他的服务器交流。请求的平均数量在每小时 85,000 个请求左右。在所有的用户位于系统中之后，每一个测试都会运行 60 分钟。
管理测试用例
在这个用例中，用户会模拟一个典型的 Rational Requirements Composer Author 应该做的操作。用户会切换至一个资源，检查资源，然后决定是否更新资源还是创建一个完全新的资源。表 1 显示了用户执行的操作。
表 1. Rational Performance Tester Author 脚本
| 描述 | 测试脚本操作 | 频率 |
|---|---|---|
| 1. 查看文件夹结构 | GetAllFolders | 100% |
| 2. 为一个文件夹中的资源 URLs 运行一个查询 | RunFolderQuery | 100% |
| 3. 运行一条查询以获取关于资源 URLs 的数据 | GetMultiDescribe | 100% |
| 4. 选择一条资源并获得它的内容 | GetArtifactContents | 100% |
| 5.运行一条查询以获得关于资源的数据 | FetchArtifactInfo | 100% |
| 6. 执行下面的一条： | ||
| ApplyAttribute | 75% |
| CreateResource | 25% |
评审用例
在这个用例中，用户会模拟一个典型的 Rational Requirements Composer Review 的操作。用户会切换以找到一条资源，然后决定是对资源添加一条评论，用相关的标记来标记资源，还是移动到另一个用例上而不进行进一步的操作。表 2 显示了用户的操作。
表 2. Rational Performance Tester Reviewer 脚本
| 描述 | 测试脚本操作 | 频率 |
|---|---|---|
| 1. 查看文件夹结构 | GetAllFolders | 100% |
| 2. 为文件夹中的资源 URLs 运行一条查询 | RunFolderQuery | 100% |
| 3. 运行一条查询以获取关于资源 URLs 的资源数据 | GetMultiDescribe | 100% |
| 4. 选择一条资源并获取它的内容 | GetArtifactContents | 100% |
| 5. 运行一条查询以获得关于资源的数据 | FetchArtifactInfo | 100% |
| 6. 执行以下内容中的一个： | ||
| CreateComment | 50% |
| TagResource | 25% |
| 25% |
Rational Performance Tester 性能日程安排
日程安排（图 3）由一些用于模拟 Author 的多个测试用例组成，并检查用例。
图 3. Rational Performance Tester 日程安排
每一个测试用例都使用 Rational Requirements Composer范例来与服务器进行交流，它是 Java 范例的收集，演示了客户和合伙人怎样使用 RESTful 请求与 Rational Requirements Composer 资源进行交流。范例程序可以在 Jazz.net 上获得。对于每一次服务器交流，每一个用户都重复使用两个 Apache HttpClient 对象来与服务器通过 HTTP 进行交流。
用户操作时间与工具
对于每一次运行的测试，用户都会在一个正常的设置间隔内引入一个系统；这个时间间隔就叫做“间歇”阶段。这就可以确保对系统引入的大量用户不会使系统超负荷运转。间歇阶段中总共的响应时间没有包含在方法之中。方法反映了当所有用户都位于系统中时所收集的数据。
失败接受
因为脚本是随机的，所以服务器的负荷量随着时间的变化而波动。在一个大到不正常的负荷量下，服务器会返回出错的代码。如果错误率低于请求总数的 15%，那么数据就认为是有效的。
VMware ESX 服务器
在 VMware ESX 服务器上，系统资源监视是使用 VMware 基础客户端性能工具来完成的，如图 4 所示。该工具支持对 CPU、内存及硬盘使用情况的监视。
图 4. VMware 基础客户端性格工具
Windows 服务器
在 Windows 服务器上，资源监视是通过使用 Windows 性能监视工具（perfmon）来完成的，如图 5 所示。
图 5. Windows 性能监视工具
VMware ESX 服务器，Linux 环境
- 程序服务器规格
- SuSE Linux® 4.1.2 64 位 VM
- WebSphere 程序服务器 7.0.0.3
- 3.0 GHz CPU 的四核 Intel Xeon X5365
- 8 GB RAM
- 50 GB SCSI 硬盘
- 数据库服务器规格
- SuSE Linux 4.1.2 64 位 VM
- DB2 9.5 版本
- 3.0 GHz CPU 的四核 Intel Xeon X5365
- 8 GB RAM.
- 50 GB SCSI 硬盘
* 查看 ESX 服务器规格的附录
Windows 环境
- 程序服务器规格
- Windows 2003 Enterprise Server，32 位
- WebSphere Application Server 6.1 版本
- Intel Core Duo E6750 @ 2.6 GHz CPU
- 4 GB RAM
- 232 GB SATA 硬盘
- 数据库服务器规格
- Windows 2003 Enterprise 服务器，32 位
- DB2 9.5.1 版本
- Oracle 10g
- Intel® Core Duo E6750，2.6 GHz CPU
- 4 GB RAM
- 232 GB SATA 硬盘
Rational Requirements Composer 创建
用户储存库
为了估计远程用户认证的变量，在本文中提到的程序服务器是本地的用户储存库（并不使用 LDAP）。WebSphere Application Server 使用的是联合的用户储存库，而 Tomcat 服务器使用的是本地的 Tomcat 用户储存库。
项目结构
本文中描述的项目结构反映了典型的客户使用，假设大多数的用户并不用访问所有储存库中的资源。项目随着数据项目一起创建，它包含了储存库中占全部资源大约 80% 的部分。每一个用户都可以访问测试项目，它占到了储存库中大约 20% 的资源。
IBM WebSphere Application Server 设置
在可以使用额外内存的 64 位机器上，Java™ Virtual Machine（JVM）最大存储规模对默认的 1536 MB 容量有所增加。这就可以确保最大容量的高效率。在一个 32 位的机器上，使用了默认的设置。
Tomcat 程序服务器设置
Tomcat 程序服务器使用了默认的设置。
为了确保最优的数据库性能，需要确保数据库得到了全部的优化。有了 DB2 和 Oracle，您就可以进行统计以让数据库分析方案的规模并优化其内容了。
数据库通常会自动管理统计数据。但是，为了确保在我们的测试期间数据库得到了全面的优化，我们需要手动运行统计过程：
DB2
DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL |
Oracle
EXEC DBMS_STATS.gather_schema_stats(' JAZZDBUSER' ); |
在这个实验中，我们比较了数据库通道的性能。测试的环境是相似的；数据库服务器同时安装了 IBM DB2 以及 Oracle。数据库服务器是冷是热，取决于测试的通道。数据通过 IBM® Jazz™ 来备份以作为一个文件系统，并同时存储在两个数据库中。
数据库通道比较是在拥有 10,000 资源以及 50 和 200 的用户的 Windows 环境中执行的。
将 IBM WebSphere Application Server 和 DB2 数据库服务器（Windows）隔离开来
Windows 32 位的环境配置了 IBM 程序服务器以与 DB2 数据库服务器相交流。对于 200 个并发用户的平均请求响应时间是 1,381 ms。在 60 分钟的运行时间内响应时间会发生自然的波动。
图 6. 拥有 10,000 资源的 DB2 数据库的平均请求响应时间
将 IBM WebSphere Application Server 与 Oracle 数据库服务器（Windows）隔离起来
Windows 32 位环境配置了 IBM WebSphere Application Server，以与 Oracle 数据库服务器相交流。200 个并发用户的平均响应时间是 1,321 ms。在 60 分钟的运行时间内响应时间会发生自然的波动。
图 7. 拥有 10,000 资源的 Oracle 数据库的平均请求响应时间
图 8. 数据库通道间平均响应时间的比较
DB2、Oracle 及 SQL （2.0.0.1 版本中支持）数据库在请求响应时间（图 8）上没有多少显著的差异。与 表 4 中的数据相联系，可以指示数据库服务器是系统中最少使用的构件, 数据库通道也可以提供最高层次的性能。所以您可以使用您或者您所在团队最喜欢使用的数据库。
将 WebSphere Application Server 与 DB2 数据库服务器（Linux）隔离开来
这些测试运行显示了评价储存库中并发用户的数量与资源数量的效果。响应时间与服务器资源得到了监视。Linux 环境用于这些运行，包括 200、350 和 500 个用户和 10,000、50,000 和 100,000 个资源。
图 9. Linux 环境下储存库规模与用户数量对比的响应时间
表 3. Linux 系统上存储库规模与用户数据数量对比的平均响应时间
| 规模 | 200 用户 | 350 用户 | 500 用户 |
|---|---|---|---|
| 10,000 资源 | 97.2 ms | 123.9 ms | 236.2 ms |
| 50,000 资源 | 101.4 ms | 150.6 ms | 318.5 ms |
| 100,000 资源 | 115.6 ms | 190.2 ms | 436.2 ms |
当我们在将 Tomcat 程序服务器与 IBM WebSphere Application Server 相比较的时候，我们可以看到在性能方面一些细微的差异。
注意：
我们使用的是默认的 WebSphere Application Server 配置。在运行我们的测试时，不会在 WebSphere 程序服务器上进行额外的性能调试。
每一个用户组在评价响应时间上的差异不会超过 55 ms。对于拥有不到 300 个用户的小型商店来说，选择可得到的并且适合您的特定需要的程序服务器。
图 10. 程序服务器比较
用户的数量
在图 10 中，随着用户数量的增长，平均的响应时间也在增长。对响应时间增长率的比较并不会显示 Tomcat 与 IBM WebSphere 程序服务器之间的显著差异。当用户增长到 300 时，使用您更喜欢的程序服务器。
用户的可评价性
在 图 9 中，用户的引入对响应时间会造成很大的影响。当用户的数量从 300 增长到 500 时，性能会发生大幅度的降低。在一个拥有 100,000 资源的存储库中，当用户数量从 350 增长到 500 时，响应时间会增长 130%，而用户从 200 增长到 350 时，响应时间只会增长 65%。这种性能上的降低，意味着拥有 350 个并发用户的负荷，已经是一个拥有 100,000 资源的存储库的最佳负荷了。
资源数量的可评价性
在 图 9 中，随着更多资源的引入，当系统中有 200 个用户时响应时间会降级。但是当系统中有 500 个用户时，资源从 50,000 增长到 100,000 会造成响应时间增长 37%；而对于一个拥有 200 个用户的系统来说，响应时间只增长了 14%。于是我们得出一个结论，对于我们所使用的 Linux 环境，当系统中有 200 个用户时，更多资源的引入会对性能造成显著的影响。这种增长是由于程序服务器上所发生的数据索引和搜索操作；因为，随着资源数量的增长，响应时间就会受到影响。
可评价性分解
让我们比较一下引入更多用户 与引入更多资源之间造成效果的差异，从上面的分析可以看出，更多用户的引入对性能的影响更加显著（见于表 3）。但是，如果我们将数据库交流与查询交流隔离出来的话，我们可以看到增加用户数量造出的影响，要比增加资源造成的更加显著。
图 11. 评价 Linux 上储存库操作和查询的影响
对于存储库的交流，数据库中行的数量，在 10,000 个资源与 100,000 个资源之间发生显著的波动，在响应时间上会发生很大的波动。但是对于涉及到 Jena 查询库的查询交流，差异就不会如此的显著了。
总结
对于一个有着更好性能的可评价服务器，使用双边的部署，一个服务器为程序服务器部署，另一个服务器为数据库服务器部署。对于大规模的部署，使用 NAS 或者 SAN 存储方案以得到高服务器负荷条件下的性能。
系统资源使用
对于系统资源，当所有用户在系统中都是激活状态时，我们比较了 WebSphere Application Server （接下来表 4 中的“ WAS”）机器资源使用以及 DB2 数据库服务器机器。
表 4. Linux 环境资源使用
| WAS* CPU 使用百分比 | WAS 使用百分比 | WAS 硬盘使用（KBps） | DB2 CPU 使用百分比 | DB2 内存使用百分比 | DB2 硬盘使用（KBps） | |
|---|---|---|---|---|---|---|
| 10,000 资源 200 用户 | 18.00 | 58.6 | 214.7 | 1.16 | 9.67 | 127.70 |
| 10,000 资源 500 用户 | 45.26 | 61.4 | 635.4 | 2.55 | 11.50 | 326.570 |
| 100,000 资源 200 用户 | 18.90 | 63.8 | 827.5 | 1.73 | 10.80 | 302.20 |
| 100,000 资源 500 用户 | 49.50 | 68.0 | 1795.0 | 2.89 | 10.96 | 435.67 |
*WAS = 网络区域程序服务器
增加资源的数量，对 WebSphere Application Server 机器的 CPU 或者内存的使用情况的影响很小，但是却能显著地影响硬盘的使用情况。对于 DB2 数据库服务器，增加资源的数量只会影响到硬盘的使用情况。而在 WebSphere Application Server 上，增加用户的数量会同时影响 CPU 及硬盘的使用情况，却不会对 DB2 服务器机器产生什么影响。当您在考虑怎样评价 Rational Requirements Composer 环境时，硬盘使用情况对 WebSphere Application Server 和 DB2 服务器机器都很重要。特别需要指出的是，对于 WebSphere Application Server 机器，注意要确保 CPU 的使用情况不会成为性能的瓶颈问题。
硬盘空间的使用情况
Rational Requirements Composer 服务器索引数据使用的硬盘空间与数据库实例需要的硬盘空间组成。默认条件下，索引的数据位于与程序服务器相同的机器上。因此，一直要考虑保持足够的硬盘空间。
例如，对于拥有 100,000 Rational Requirements Composer 资源的 Linux 存储库来说，索引的数据占据了多达 10 GB 的硬盘空间。数据库实例必须位于拥有合适硬盘空间的服务器上。例如，拥有 100,000 Rational Requirements Composer 资源的数据库大约相当于 17 GB 的硬盘空间。
注意：
在我们的测试之中，我们使用了简化的资源，以及没有优先级别的资源，所以实际的硬盘空间使用情况随着资源数量和内容的不同而发生变化。
网络带宽使用
在测试期间，我们同时监视了在服务器上运行的 IBM WebSphere Application Server 软件，以及 DB2 服务器的网络使用情况。
注意：
默认条件下，包括了所有我们进行的测试，所有的内容都会从 Rational Requirements Composer 服务器转移到使用 HTTP 压缩的客户端连接上面，HTTP 压缩也就是 gzip 压缩规则。
所有的客户端连接都使用 HTTPS。图 12 显示了使用不断增长的资源与用户，在我们的测试期间 WebSphere Application Server 和 DB2 服务器的网络带宽的使用情况。
表 5. Linux 环境网络使用
| 资源和用户 | WebSphere 网络使用（KBps） | DB2 网络使用（KBps） |
|---|---|---|
| 10,000 资源，200 个用户 | 209.6 | 145.7 |
| 10,000资源，500 个用户 | 564.8 | 399.4 |
| 100,000资源，200 个用户 | 214.9 | 149.6 |
| 10,000资源，500 个用户 | 557.2 | 387.9 |
从结果中可以看到 WebSphere Application Server 服务器网络使用要比 DB2 服务器的网络使用高出 40%。考虑到这些数量，您应该意识到在您创建服务器环境时，网络使用情况是一个考虑因素：WebSphere Application Server 要使用比 DB2 服务器更多的带宽。
硬件的规模
通过使用我们汇编的测试数据，我们创建了以下的表格，基于 Rational Requirements Composer 服务器最优部署的各种不同的硬件与软件配置。在考虑规模选项时，2.0 版本同时支持单人配置以及多人配置。您可以选择低成本的单边配置，并且可以在团队规模扩增的情况下添加一台机器（双边配置）。
接下来的列表显示了不同企业部署的规模。
小型企业配置，10,000 资源与最多 100 个用户：
- 2 系统：四核 CPU 2.4 GHz 或者更高，64 位
- 内存：4 GB 或者更高
- 操作系统：Linux 或者 Windows 服务器
- Web 程序服务器：Tomcat 5.5 或者 WebSphere Application Server 6.1 或者后续版本
- 数据库：Oracle 10GR2 或者 DB2 9.1 版本或者 DB2 9.5 版本 Fix Pack 4
中等规模企业配置，50,000 资源与最多 250 个用户：
- 2 系统：四核 CPU 2.4 GHz 或者更高，64 位
- 内存：8 GB 或者更高
- 硬盘：高性能 SAS 硬盘（15K），RAID
- 操作系统：Linux 或者 Windows 服务器
- Web 程序服务器：Tomcat 5.5 或者 WebSphere Application Server 6.1 或者后续版本
- 数据库：Oracle 10GR2 或者 DB2 9.1 版本或者 DB2 9.5 版本 Fix Pack 4
大规模企业配置，100,000 资源和最多 500 用户：
- 2 系统：四核 CPU 2.4 GHz 或者更高，64 位
- 内存：8 GB 或者更高
- 硬盘：高性能 SAS 硬盘（15K）、RAID、 SAN 或者 NAS 直接联系的硬盘子系统
- 操作系统：Linux 或者 Windows 服务器
- Web 程序服务器：Tomcat 5.5 或者 WebSphere Application Server 6.1 或者后续版本
- 数据库：Oracle 10GR2 或者 DB2 9.1 版本或者 DB2 9.5 版本 Fix Pack 4
网络连接性
在双边配置中选择网络的连接性就是降低程序服务器与数据库服务器之间的潜在问题（不超过 1-2 ms）。当您在使用外部存储时，减少连接的潜在问题（最佳的配置是通过一个 Fibre Channel 进行的）。
硬盘
基于性能测试的结果，我们发现了资源的增长随着并发用户的增长，会导致硬盘负荷的增长。因此，对于大规模部署的存储情况，考虑一下存储直接通过 Fibre Channel（FC）连接，以避免存储和服务器之间潜在情况的存在。使用这种配置的好处在于允许从服务器到 NAS 的所有硬盘 I/O，同时提供了一个完整的故障容忍硬盘子系统，它带有即时快照备份功能以及高可用性和故障恢复功能。
我们创建了一个单独的可靠性测试，以在一个扩展的时期内观察服务器的运转状况。该测试环境的配置与前面描述的相似。配置本身在 Appendix 中指定了：可靠性测试环境。
可靠性测试的目的在于在 5 到 7 天的持续使用期间，决定 Rational Requirements Composer 服务器的性能与稳定性。这种测试会在一个相当长的测试时间内应用不同的工作负荷，来评价 Rational Requirements Composer 服务器的性能特征，除此之外，还要评价内存的消费情况以及 CPU 的使用情况。
在初始的创建之后，内存的使用会停留在一个给定的范围之中，而负荷量会有一定的增长（见于图 12）。对于处理器的使用也可以看到相类似的情况（图 13）。在一定的负荷下，处理器使用可能会发生波动，但是并不会一直停留在很高的程度上。
在测试的过程中，服务器保持了 100% 的负荷。
图 12. Server Memory Available 图表
图 13. Server Processor Time 图表
正如在 Failure Acceptance 下面所注意的那样，测试运行时的错误代码返回容忍门槛为 5%。这些错误通常只在高负荷的情况下发生，此时大量的并发用户以及大量的存储数据已经接近了测试参数的最高界限（500 个用户，100 KB 的资源）。
对服务器的观察（负荷会发生波动）显示高负荷下产生的错误，不会造成什么长时间的影响，或者对其他的请求造成什么负面的效果。这种行为可以归结为 Rational Requirements Composer 服务器的“无述”结构。
高负荷下 OAuth 的计时错误
高负荷下产生错误的一般原因仍然可以回溯到响应时间。在本文这种条件下，这里指的响应时间不是 Rational Requirements Composer 服务器与客户端之间的响应时间，而是 Rational Requirements Composer 服务器与 Jazz Foundation Services 之间的响应时间。
Rational Requirements Composer 服务器对 Jazz Foundation Services 所做的每一条请求都使用 OAuth 协议进行认证（查看 参考资料 部分以得到更加具体的内容）。这段时间发生在 Rational Requirements Composer 服务器得到访问令牌并拥有 Jazz Foundation Services 服务的请求之间。如果这段时间要比配置的 OAuth Access Token Timeout 更长，那么请求就会失败，因为 Jazz Foundation Services 将会拒绝 Rational Requirements Composer 服务器的请求。在这种情况下，服务器日志应该报告 OAuth Access Tokens 正处于繁忙中。
图 14. 高级的服务器属性
OAuth 设置可以在 OAuthServiceProvider 标题下面找到，如图 15 所示。
图 15. OAuth Timeout 属性
增加访问令牌繁忙值就可以允许更多的请求通过，并降低繁忙错误产生的几率，因此提高了系统整体的可靠性。当然，这样做的代价是增加了 Rational Requirements Composer 客户端与服务器之间的响应时间，因为需要更长的时间来完成请求。
注意：
请求的繁忙值会发生变化，它取决于服务器的配置情况。
编辑日程安排服务器任务的频率
还有一些服务器任务会根据安排表来执行。当这些任务发生时，会对服务器造成很重的负荷。根据 Rational Requirements Composer 资源使用的情况，服务器负荷量的多少可以在安排的任务运行时发生变更。您可以按照日程安排任务的指导来编辑它们：
- 最近的供给任务
日程安排上有四个发生更新的任务：最近的工件，最近的需求，最近的评论以及标签的数量。这些任务对于每一个Rational Requirements Composer 项目都分别运行。取决于工件、需求和评论创建或者更新的频率，也可以降低任务的性能影响。使用下面的指导原则：
- 如果有一种特定类型的操作并不是经常执行，那么其频率可以降低。
- 如果有一种特定类型的操作经常执行，那么相应任务的频率可以增加以降低每一项任务必须执行任务的数量。
- 如果一种特定类型的任务并不重要，那么其频率可以降低以减少工作的数量。
- 降低任务的发生率可以阻止所有的任务在同一时间执行，因此产生了一种情况，在一个给定的时期内，服务器请求会得到缓慢的处理。
如果您想更改任务的评论，您必须先更改 fronting.properties 文件。该文件的位置是：
<server installation directory>/conf/rdm/fronting.propreties。
有一些相应的属性（所有的属性值单位都是毫秒，或者 ms）：
最近的评论集
它决定了哪些评论会出现在最近的评论集中。由评论的创建或者更新操作激发。
com.ibm.rdm.fronting.server.RDMRecentCommentsUpdate.interval=360000
测试期间使用的值：300,000
最近的工件单
这决定了哪些工件会出现在最近的工件单种，由 Rational Requirements Composer 资源的创建或者更新操作激发。
com.ibm.rdm.fronting.server.RDMRecentArtifactsUpdate.interval=420000
测试期间使用的值：420,000
最近的需求单
决定哪些工件出现在最近的需求单上。由 Rational Requirements Composer 需求资源的创建或者更新操作激发
com.ibm.rdm.fronting.server.RDMRecentRequirementsUpdate.interval=300000
测试期间使用的值：540,000
标签统计
决定每一个公共标签的使用数量。由资源的标记和不标记而激发。
com.ibm.rdm.fronting.server.RDMTagCountUpdate.interval=900000
测试期间使用的值：900,000
- Jazz 索引持续性间隔
这个间隔值意味着了在索引任务中记录工作的进展状况。当记录保存后，这个期间所作的请求将要比平常的响应时间更长。因此，通过增加持续性间隔，可以降低停滞阶段的时间。当进展是持续性的时候，就可以保存更多的数据了。因此，如果有大量的资源创建或者更新操作，那么您就可以降低持续性间隔。如果存储库使用主要是只读性的操作，那么您可以增加持续性间隔以提供更好的性能。
持续性属性使用 Jazz Admin 页面和所需的管理员权限来进行更改。
高级属性：每 N 秒持续索引进展
默认的值是 60000 ms （1 分钟）
测试期间使用的值：600,000 ms
图 16. 索引持续间隔高级设置
感谢系统确认测试团队中的 Mario Maldari、René Morrow、 Jim Yen、Ronald Li、Bhavin Shah 和 Li Ping Li 提供了关于可靠性测试的信息。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780914/viewspace-671817/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780914/viewspace-671817/
扫一扫
3789
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
