本文描述如何部署 Apache 開放源代碼工具 JMeter，以基於 IBM WebSphere Application Server 和 WebSphere Branch Transformation Toolkit（BTT）來測試中間件解決方案的響應性。通過設計性能測試，可以模擬變化的併發用戶負載，這些用戶負載使用多種交互式金融交換（Interactive Financial eXchange，IFX）請求消息。如果您項目的性能測試預算有限，並且您的解決方案使用 XML 消息，那麼在本文結尾所得出的經驗可以幫助您計劃自己的性能測試策略。
|
獲取本文中所使用的產品和工具 |
針對高可見性項目的性能測試挑戰
一個金融機構的近期項目需要交付一箇中間件基礎設施，用於支持增長的應用程序列表，這些應用程序需要訪問企業的核心金融系統。該體系結構的方向是要求所有的核心金融系統請求都經由該中間件解決方案，該方案使用基於 XML 的 IFX 消息標準。圖 1 顯示了與第一個應用程序有關的中間件基礎設施（以粗體顯示），以及未來的應用程序和後端系統（以灰色顯示）。
要使得該高可見性項目獲得認可，必須演示在各種負載之下的最佳性能。這對於響應時間敏感的客戶來說尤爲重要，例如聯絡中心的 CRM 應用程序。另一個需要考慮的問題是，當新的應用程序出現在中間件的“前面”和“後面”時（圖 1 中顯示了一個位於中間件“後面”的企業和消費者信用卡服務系統的未來實現），需要重用已選擇的性能測試方法。
無用戶接口
指定使用中間件基礎設施的第一個應用程序是存款處理應用程序，它預定在中間件項目完成之後實現。這意味着測試團隊不得不在沒有用戶接口可以準備和提交中間件請求的情況下模擬生產負載。
有限預算
金融機構並沒有合適的工具集來支持中間件性能測試。因此，這裏的挑戰是確信地報告已觀察到的中間件性能特性，同時將用於工具和準備工作的預算保持最小。
使用 JMeter 救急
通過研究各種可用的開放源代碼測試工具，發現 Apache JMeter 可以支持中間件性能測試需求。 JMeter 提供一個基於 GUI 的應用程序，用於設計和執行多種可重用的測試計劃。JMeter 還支持以 XML 格式捕捉測試結果，用於測試後的統計分析。這兩個特性幫助測試團隊開發和文檔化可重複的測試結果，從而滿足“高可見性”的挑戰。
許多開放源代碼的測試工具是設計用於測試 Web 站點的，並期望測試能夠模擬用戶與一個或者多個頁面或表單的交互。因爲在測試中間件解決方案時，應用程序的 Web 接口並不可用，所以已選擇的工具必須在沒有瀏覽器交互的情況下支持基於 XML 的消息。JMeter 的 SOAP/XML 請求組件滿足該要求。
最後，由於 JMeter 是 Apache 軟件基金會的產品，這個事實意味着該項目並不要求支付商業測試工具的許可證費用，從而滿足“有限預算”的條件。
設計測試腳本
性能測試的目標是，在各種併發負載條件下提交隨機選擇的、預先定義的、IFX 編碼的請求消息，並記錄接收到 IFX 編碼的響應的耗用時間（elapsed time）。下面五個 JMeter 測試計劃組件用於準備性能測試腳本。
測試計劃
這是用於測試的主要組件。在這裏，測試名是根據項目的命名約定指定的。同時，選擇 Functional Test Mode，以便在由 View Results Tree 管理的測試結果中捕獲完整的 IFX 編碼的響應。
HTTP Header Manager
該組件用於指定中間件所需要的 HTTP 頭的值。發送到中間件的每個 IFX 編碼的請求都將包括這些 HTTP 頭的值。
圖 3. JMeter HTTP Header Manager
Thread Group
該組件按照測試計劃的要求進行重複，以模擬一個特定數目的併發用戶。例如，模擬 5 個併發用戶，需要指定 5 個 Thread Group。
注意，Thread Group 組件具有一個標籤爲 Number of Threads 的域，用於控制與一個 Thread Group 相關聯的線程數目。由於每個 Thread Group 具有一個惟一的隨機選擇的 IFX 編碼的請求集合（請參閱下面的 SOAP/XML-RPC Request），因此決定將每個 Thread Group 限制爲一個線程。如果對於一個或者多個 Thread Group 指定多個線程，那麼相同的消息集合將會被髮送多次，這將違背隨機選取準則的目標。
SOAP/XML-RPC Request
針對每個 Thread Group 所發送的期望數目的 IFX 編碼請求，重複該組件。實際的 IFX 編碼的請求是在該組件中指定的。
圖 5. JMeter SOAP/XML-RPC Request
View Results Tree
該組件服務於兩個目的。當測試執行時，該用戶接口顯示消息被髮送和接收的測試過程。而且，該組件將測試結果寫入到一個文件，用於測試後的分析。
JMeter 測試計劃被設計用於模擬多種併發用戶負載，從單一用戶到最大爲 80 個併發用戶。對於所有的測試計劃，上面所描述的五個組件以一致的方式進行部署，從而簡化了性能測試的執行。
構建測試腳本
一旦已經確定所需的 JMeter 組件並且已經構思好一個通用的測試計劃設計，就必須構建測試腳本了。幸運的是，System Integration Test （請參閱 參考資料）中有超過 300 個 IFX 編碼的模型請求消息和相關的測試數據可以重用。相應的挑戰是準備測試腳本可以發送多達 8000 個（對於 80 個線程，每個線程 100 個）隨機選擇的請求消息。這些消息是隨機選擇的，從而更好地接近生產條件的穩定狀態，生產條件下沒有一個請求類型可能會比其他類型提交得更多。單獨使用 JMeter 用戶接口，將意味着手工剪切和粘貼消息到 8000 個 SOAP/XML-RPC Request 中。爲了使得該任務進一步複雜化，根據金融機構的 IFX 規範，每個請求還要求惟一的 RQUID。
自動創建測試腳本
正如已經提到的，該項目的性能測試方法將針對未來的中間件版本進行重用。因此，測試團隊投入一些精力準備一個 Java 應用程序，用於根據指定的參數輸出 JMeter XML 編碼的測試腳本。該 Java 應用程序稱爲 Scripter，它可以準備一個性能測試腳本，該腳本具有指定數目的線程並且每個線程具有指定數目的 IFX 編碼的消息，由應用程序隨機選擇。IFX 編碼的消息來源於一個消息集合，該集合在 Scripter 的屬性文件所指定的目錄中提供。
從本文 參考資料 小節中的鏈接，您可以下載 Scripter Java 應用程序的源代碼和用法說明。
執行測試
JMeter 安裝在一個 雙通道的 IBM eServer™ xSeries® 360 服務器上，該服務器具有 2 GB RAM 並且運行 Windows® 2000。圖 7 顯示測試配置。
當測試執行時，IFX 編碼的響應被記錄，從而可以分析包含在中間件響應中的捕獲到的 MQ Time 和 Total Time 度量。還可以分析 JMeter 觀察到的 JMeter Time，儘管該數字還包括在中間件和 JMeter 之間的網絡延遲。
測試團隊執行三個性能測試周期，在前兩個週期之後通過修改和配置調整從而改進應用程序的性能。
分析結果
測試團隊使用 Microsoft® Excel 電子數據表來導入測試結果，並且針對上面描述的耗用時間度量執行統計運算。然後，結果被圖形化，從而顯示該應用程序對於大多數測試條件提供的次秒級（sub-second）響應性。
獲得的經驗
總的說來，JMeter 作爲該項目的性能測試工具是一個極好的選擇。下面所獲得的經驗提供另外的細節。
JMeter 滿足我們的需要
JMeter 易於安裝並且具有中等的認識複雜度（請參閱下一條經驗）。所選擇的 JMeter 組件針對所有的性能測試腳本提供了一個公共的結構。測試結果的 XML 編碼輸出對於測試後分析是一個方便的特性，因爲該選項捕獲了包含在 IFX 編碼的應答消息中的性能統計。
JMeter 用戶應該具有技術能力
爲了正確地準備性能測試腳本，腳本開發人員必須很好地理解使用 HTTP 和 XML 協議的分佈式應用程序。商業用戶可能發現難以使用各種 JMeter 組件的技術規範。
創建大的腳本可能需要額外的自動化處理
我們的性能測試特性（隨機的消息選取，併發性，以及包含在每個 IFX 編碼的請求中的惟一值）要求一個自動化的方法產生測試腳本。幸運的是，測試團隊具有足夠的 Java 技術能力使得該任務自動化。對於具有類似需要的人，本文的末尾提供了該應用程序。
如果時間（和能力！）允許的話，團隊還可以開發一個新的符合該項目需要的 JMeter 組件，並且將該組件提交給 Apache 組織。
定製的性能度量可以幫助確定問題
JMeter 應用程序可以測量在傳輸 IFX 編碼的請求和接收 IFX 編碼的應答之間的耗用時間。然而，該度量並不提供有關該分佈式中間件解決方案所存在的潛在瓶頸的內部信息。中間件開發團隊提供另外的性能度量，將用於主機通信、消息分析的耗用時間與用於事務處理的中間件耗用時間隔離開來。這些度量作爲 XML 註解包含在 IFX 編碼的應答中。