IBM Rational Requirements Composer 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 上的可瀏覽圖形。

Web 程式伺服器

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 伺服器上執行模擬使用者的結果。實際的客戶經驗可能會與之不同，這取決於客戶所在的環境與使用情況。

Rational Performance Tester

IBM® Rational® Performance Tester 用於模擬和評價 Rational Requirements Composer 客戶端/伺服器交流。測試環境得以建立以處理那些與 Rational Requirements Composer 伺服器相交流的 500 個虛擬使用者。

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 顯示了使用者執行的操作。

評審用例

在這個用例中，使用者會模擬一個典型的 Rational Requirements Composer Review 的操作。使用者會切換以找到一條資源，然後決定是對資源新增一條評論，用相關的標記來標記資源，還是移動到另一個用例上而不進行進一步的操作。表 2 顯示了使用者的操作。

Rational Performance Tester 效能日程安排

日程安排（圖 3）由一些用於模擬 Author 的多個測試用例組成，並檢查用例。

圖 3 的大圖

每一個測試用例都使用 Rational Requirements Composer範例來與伺服器進行交流，它是 Java 範例的收集，演示了客戶和合夥人怎樣使用 RESTful 請求與 Rational Requirements Composer 資源進行交流。範例程式可以在 Jazz.net 上獲得。對於每一次伺服器交流，每一個使用者都重複使用兩個 Apache HttpClient 物件來與伺服器通過 HTTP 進行交流。

使用者操作時間與工具

對於每一次執行的測試，使用者都會在一個正常的設定間隔內引入一個系統；這個時間間隔就叫做“間歇”階段。這就可以確保對系統引入的大量使用者不會使系統超負荷運轉。間歇階段中總共的響應時間沒有包含在方法之中。方法反映了當所有使用者都位於系統中時所收集的資料。

失敗接受

因為指令碼是隨機的，所以伺服器的負荷量隨著時間的變化而波動。在一個大到不正常的負荷量下，伺服器會返回出錯的程式碼。如果錯誤率低於請求總數的 15%，那麼資料就認為是有效的。

系統資源監視

VMware ESX 伺服器

在 VMware ESX 伺服器上，系統資源監視是使用 VMware 基礎客戶端效能工具來完成的，如圖 4 所示。該工具支援對 CPU、記憶體及硬碟使用情況的監視。

圖 4 的大圖

Windows 伺服器

在 Windows 伺服器上，資源監視是通過使用 Windows 效能監視工具（perfmon）來完成的，如圖 5 所示。

測試機器規格

VMware ESX 伺服器，Linux 環境

1. 程式伺服器規格
   • 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 硬碟
2. 資料庫伺服器規格
   • 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 環境

1. 程式伺服器規格
   • Windows 2003 Enterprise Server，32 位
   • WebSphere Application Server 6.1 版本
   • Intel Core Duo E6750 @ 2.6 GHz CPU
   • 4 GB RAM
   • 232 GB SATA 硬碟
2. 資料庫伺服器規格
   • 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 REORGCHK UPDATE STATISTICS ON TABLE ALL

				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 分鐘的執行時間內響應時間會發生自然的波動。

將 IBM WebSphere Application Server 與 Oracle 資料庫伺服器（Windows）隔離起來

Windows 32 位環境配置了 IBM WebSphere Application Server，以與 Oracle 資料庫伺服器相交流。200 個併發使用者的平均響應時間是 1,321 ms。在 60 分鐘的執行時間內響應時間會發生自然的波動。

資料庫比較

DB2、Oracle 及 SQL （2.0.0.1 版本中支援）資料庫在請求響應時間（圖 8）上沒有多少顯著的差異。與 表 4 中的資料相聯絡，可以指示資料庫伺服器是系統中最少使用的構件, 資料庫通道也可以提供最高層次的效能。所以您可以使用您或者您所在團隊最喜歡使用的資料庫。

使用者與資源可評價性的結果

將 WebSphere Application Server 與 DB2 資料庫伺服器（Linux）隔離開來

這些測試執行顯示了評價儲存庫中併發使用者的數量與資源數量的效果。響應時間與伺服器資源得到了監視。Linux 環境用於這些執行，包括 200、350 和 500 個使用者和 10,000、50,000 和 100,000 個資源。

網路程式伺服器的比較

當我們在將 Tomcat 程式伺服器與 IBM WebSphere Application Server 相比較的時候，我們可以看到在效能方面一些細微的差異。

注意：
我們使用的是預設的 WebSphere Application Server 配置。在執行我們的測試時，不會在 WebSphere 程式伺服器上進行額外的效能除錯。

每一個使用者組在評價響應時間上的差異不會超過 55 ms。對於擁有不到 300 個使用者的小型商店來說，選擇可得到的並且適合您的特定需要的程式伺服器。

使用者的數量

在圖 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）。但是，如果我們將資料庫交流與查詢交流隔離出來的話，我們可以看到增加使用者數量造出的影響，要比增加資源造成的更加顯著。

對於儲存庫的交流，資料庫中行的數量，在 10,000 個資源與 100,000 個資源之間發生顯著的波動，在響應時間上會發生很大的波動。但是對於涉及到 Jena 查詢庫的查詢交流，差異就不會如此的顯著了。

總結

對於一個有著更好效能的可評價伺服器，使用雙邊的部署，一個伺服器為程式伺服器部署，另一個伺服器為資料庫伺服器部署。對於大規模的部署，使用 NAS 或者 SAN 儲存方案以得到高伺服器負荷條件下的效能。

規模

系統資源使用

對於系統資源，當所有使用者在系統中都是啟用狀態時，我們比較了 WebSphere Application Server （接下來表 4 中的“ WAS”）機器資源使用以及 DB2 資料庫伺服器機器。

*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 伺服器的網路頻寬的使用情況。

從結果中可以看到 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 的大圖

圖 13 的大圖

錯誤容忍情況

正如在 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 正處於繁忙中。

OAuth 設定可以在 OAuthServiceProvider 標題下面找到，如圖 15 所示。

增加訪問令牌繁忙值就可以允許更多的請求通過，並降低繁忙錯誤產生的機率，因此提高了系統整體的可靠性。當然，這樣做的代價是增加了 Rational Requirements Composer 客戶端與伺服器之間的響應時間，因為需要更長的時間來完成請求。

注意：
請求的繁忙值會發生變化，它取決於伺服器的配置情況。

效能扭曲

編輯日程安排伺服器任務的頻率

還有一些伺服器任務會根據安排表來執行。當這些任務發生時，會對伺服器造成很重的負荷。根據 Rational Requirements Composer 資源使用的情況，伺服器負荷量的多少可以在安排的任務執行時發生變更。您可以按照日程安排任務的指導來編輯它們：

1. 最近的供給任務

日程安排上有四個發生更新的任務：最近的工件，最近的需求，最近的評論以及標籤的數量。這些任務對於每一個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

2. Jazz 索引持續性間隔

這個間隔值意味著了在索引任務中記錄工作的進展狀況。當記錄儲存後，這個期間所作的請求將要比平常的響應時間更長。因此，通過增加持續性間隔，可以降低停滯階段的時間。當進展是持續性的時候，就可以儲存更多的資料了。因此，如果有大量的資源建立或者更新操作，那麼您就可以降低持續性間隔。如果儲存庫使用主要是隻讀性的操作，那麼您可以增加持續性間隔以提供更好的效能。

持續性屬性使用 Jazz Admin 頁面和所需的管理員許可權來進行更改。

高階屬性：每 N 秒持續索引進展

預設的值是 60000 ms （1 分鐘）

測試期間使用的值：600,000 ms

感謝系統確認測試團隊中的 Mario Maldari、René Morrow、 Jim Yen、Ronald Li、Bhavin Shah 和 Li Ping Li 提供了關於可靠性測試的資訊。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-671817/，如需轉載，請註明出處，否則將追究法律責任。