IBM®
直接進入主要内容
    Taiwan  [選擇 ]      使用條款
 
 
    
     首頁      產品      服務與解决方案      技術支援與下載      個人專區     
直接進入主要内容

developerWorks 台灣  >  Open source  >

利用 Apache JMeter 測試 WebSphere 效能

一個用於測試 IFX 訊息中間元件的理想開放原始碼工具

developerWorks
文件選項

需要JavaScript的文件選項無法顯示

範例程式



級別: 入門

Greg Herringer, IT 架構師

2004 年 6 月

如果您預算緊張並且時間緊迫 —— 或者即使您不是這樣 —— 那麼,您可能希望考慮使用 JMeter 來對 Web 和其他應用程式進行壓力測試。IBM 的 Greg Herringer 詳細描述他使用這個純 Java 應用程式來測試 WebSphere 中間元件解決方案的經歷。

本文描述如何部署 Apache 開放原始碼工具 JMeter,以基於 IBM WebSphere Application Server 和 WebSphere Branch Transformation Toolkit(BTT)來測試中間元件解決方案的回應性。透過設計效能測試,可以模擬變化的併發用戶負載,這些用戶負載使用多種互動式金融交換(Interactive Financial eXchange,IFX)請求訊息。如果您專案的效能測試預算有限,並且您的解決方案使用 XML 訊息,那麼在本文結尾所得出的經驗可以幫助您計畫自己的效能測試策略。

獲取本文中所使用的產品和工具

如果您是一個 developerWorks 訂閱者,那麼您將具有一個單用戶許可證,可以使用 WebSphere Application Server 和其他的 DB2®、Lotus®、Rational®、Tivoli® 以及 WebSphere® 產品 —— 其中包括基於 Eclipse 的 WebSphere Studio IDE,來開發、測試、評估和示範您的應用程式。如果您不是一個訂閱者,您可以 現在訂閱

針對高可見性專案的效能測試挑戰

一個金融機構的近期專案需要交付一個中間元件基礎設施,用於支援增長的應用程式列表,這些應用程式需要存取企業的核心金融系統。該架構的方向是要求所有的核心金融系統請求都經由該中間元件解決方案,該方案使用基於 XML 的 IFX 訊息標準。圖 1 顯示了與第一個應用程式有關的中間元件基礎設施(以粗體顯示),以及未來的應用程式和後端系統(以灰色顯示)。


圖 1. 待測試的解決方案
圖 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 編碼的響應。


圖 2. JMeter 測試計畫
圖 2. JMeter 測試計畫

HTTP Header Manager

該元件用於指定中間元件所需要的 HTTP 標頭的值。發送到中間元件的每個 IFX 編碼的請求都將包括這些 HTTP 標頭的值。


圖 3. JMeter HTTP Header Manager
圖 3. JMeter HTTP Header Manager

Thread Group

該元件按照測試計畫的要求進行重複,以模擬一個特定數目的併發用戶。 例如,模擬 5 個併發用戶,需要指定 5 個 Thread Group


圖 4. JMeter Thread Group
圖 4. JMeter 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
圖 5. JMeter SOAP/XML-RPC Request

View Results Tree

該元件服務於兩個目的。當測試執行時,該用戶介面顯示訊息被發送和接收的測試過程。而且,該元件將測試結果寫入到一個檔案,用於測試後的分析。


圖 6. JMeter View Results Tree
圖 6. JMeter 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 顯示測試設定。


圖 7. JMeter 效能測試設定
圖 7. JMeter 效能測試設定

當測試執行時,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 編碼的應答中。




回到頂端


下載

名稱檔案大小下載方式
os-jmeter/scripter.zip  FTP
我應該選擇哪種下載方式取得 Adobe® Reader®


回到頂端


參考資料



回到頂端


關於作者

Greg Herringer 是一位 IT 架構師,他在客戶關係管理和聯絡中心技術方面具有 15 年的從業經驗,重點關注金融服務和公共部門行業。他具有跨越整個應用開發生命週期的豐富經驗。可以透過 gherring@ca.ibm.com 與他取得連絡。




回到頂端


對本文的評價

不甚滿意!(1)
可再加強 (2)
持平 (3)
相當不錯 (4)
受益匪淺!(5)



回到頂端


Other company, product, or service names may be trademarks or service marks of others.


    關於IBM隱私權條款聯絡我們