級別: 入門 Jack Shirazi, 董事, JavaPerformanceTuning.com
Kirk Pepperdine, 首席技術官, JavaPerformanceTuning.com
2003 年 12 月 18 日 最佳化大師 Jack Shirazi 和 Kirk Pepperdine 分別是 JavaPerformanceTuning.com 的董事和首席技術官，他們從事全球 Internet 上的效能問題討論。在 TheServerSide.com 留言板上最近提出了一些關於壓力測試和負載測試的問題。Jack 和 Kirk 詳細探討了這一主題，並討論了正確的工具如何導致結果產生巨大的差別。
TheServerSide.com 討論板通常是相當活躍的，所以這個月我們駐步於此以了解在效能世界中發生了什麼事情。討論板的名字就是 TheServerSide，所以在這裡討論的效能集中於 J2EE 系統是很正常的。當然，這是一個相當廣泛的題目，因為它包含了 Java 平台中的幾乎所有內容──連 J2ME 系統常常也是 J2EE 系統的Client，所以有時您甚至可以遇到關於最佳化 J2ME 系統的問題。
壓力測試和負載測試
在效能列表中最常問的問題是：“是否有一種工具可以幫助我對 J2EE 應用程式進行壓力測試？” 在回答這個問題之前，讓我們問一問自己：壓力測試是什麼，為什麼這些開發人員需要它？（我相信你們中相當一部分人曾經遇到一定要在昨天完成測試這種讓您感到壓力的情況，但是我們在這裡說的不是這個）。壓力測試是為了發現在什麼條件下您的應用程式的效能會變得不可接受。這透過改變應用程式的輸入以對應用程式施加越來越大的負載並測量在這些不同的輸入時效能的改變來實現的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試──增加使用者數量以對應用程式進行壓力測試。
對應用程式進行壓力測試最簡單的方法是手動改變輸入（Client數量、需求大小、請求的頻率、請求的混合程度，等等）並描繪效能的變化。對於一些應用程式，您需要做的就是這些。但是如果有許多輸入，或者需要在大的範圍內改變輸入，那麼就可能需要一個自動化的工具。另外，在手動測試中，如果想在進行一些改變後重新測試應用程式，可能很難精確地迭代一組測試。如果是讓多個使用者測試您的應用程式，那麼幾乎不可能一致性地執行手動測試，除非您有很多失業的朋友，否則擴大測試應用程式的使用者數量是非常困難的。
沒有一刀切的方案
不幸的是，沒有一種通用的壓力測試工具，因為每一個應用程式所接受的輸入以及對它們進行處理的方式都是不同的。但是對於許多 J2EE 應用程式來說，從Client到達伺服器的通信使用的是 HTTP 協定。幸運的是，有許多負載測試工具可以以一種可控制和迭代的方式類比 HTTP 上的使用者活動。它們包括免費工具如 Apache JMeter、The Grinder 以及 PushToText，和相當昂貴的工具如 Mercury Astraload。一般來說一分錢一分貨──工具越貴，它能做的事情就越多。為了了解它們的差別，我們首先來看最基本的負載測試工具能做些什麼。
如果您想建構自己的負載測試工具，那麼您會首先撰寫一個對每一個模擬Client執行一個執行緒的程式。每一個執行緒需要與伺服器通信，可能使用
java.net.URL 類別。這種方法使您得到基本的 HTTP Client模擬，它可以執行 GET 和 PUT。每個執行緒需要做的就是發送 HTTP 請求、收集回復、等待一些時間（模擬“考慮時間”），再迭代。這一組行動可以相當容易地抽象到一個單獨的設定檔中。很快，您就得到一個基本的負載測試工具。您可能需要增加一些設定選項以確定執行多少個執行緒（模擬的Client）以及它們是同時開始還是慢慢增加負載。當然，您需要對與伺服器的互動計時，因為這是您要測試的核心內容。
如果這麼簡單……
那麼，對於處理擴充的互動（即一個請求取決於上一個請求的結果）如何呢？對於處理 cookies 如何呢？cookies 對於許多導向session的 J2EE 系統是必不可少的。改變資料登入呢？如果 J2EE 應用程式Client需要處理一些 JavaScript 以進入下一次通信呢？在收集了回應時間資料後，如何對它進行分析？其他類型的監視，如 CPU 時間、網路使用、堆大小、分頁活動或者資料庫活動呢？
像這樣和其他的功能，如用於記錄瀏覽器session並將它們加入到測試腳本中的工具，是高階負載測試工具與基本工具的差別所在。如何為自己選擇正確的工具呢？當然，這取決於您的需要、您的計畫和您的預算。最重要的是，您需要使用可以正確地類比您的應用程式要求的使用者瀏覽器功能的工具。具備了基本功能後，可以考慮工具的生產率。一般來說，包含的分析工具越多，可以記錄的效能資料類型越多，您可以達到的生產率就越高──您願意付的錢也就越多。頂級的負載測試程式可以類比多個瀏覽器，與大多數應用伺服器整合，收集多個伺服器主機的效能資料（包括作業系統、JVM 和資料庫統計數位），產生可以在以後用進階的分析工具分析的資料集。另一方面，低端負載測試程式是免費的。在那些預算有限的日子裡，“免費”的意義是不言自明的。
圖 1 展示了免費的負載測試程式 Apache JMeter，它顯示了一個自動記錄的腳本。
圖 1. JMeter 顯示一個自動記錄的腳本
豐富的功能
我們已經看過了壓力測試工具的基本功能，還適合增加什麼附加功能呢？不同的負載測試工具的區別在什麼地方呢？當然，您最主要的要求是這個工具必須可以類比您的應用程式Client。如果您的應用程式使用一些不常見的瀏覽器功能組合或者其他非標準Client技術，那麼就排除了相當一部分候選者。除此之外，還有其他功能使負載測試的生產率更高。對於決定適合於自己專案的負載測試工具，下面的列表是一個有用的出發點：
模擬您的Client
首要要求一定是負載測試程式能夠處理您的應用程式所使用的功能和協定。
執行多個模擬的Client
這是負載測試程式最基本的功能，它有助於確定哪些是負載測試程式以及哪些不是（一些框架試圖偽裝成負載測試程式）。
腳本化執行並能編輯腳本
如果不能撰寫Client與伺服器之間互動的腳本，那麼就不能處理除最簡單的Client之外的任務東西。編輯腳本的能力是最基本的──小的改變不應該要求您重新產生腳本。
支援session
負載測試程式如果不支援session或者 cookies，那麼就不算是真正的負載測試程式，並且不能對大多數 J2EE 應用程式進行負載測試。
可設定的使用者數量
測試程式應該可以讓您指定每個腳本由多少個模擬使用者執行，包括讓您隨時間改變模擬使用者的數量，因為許多負載測試應該從小的使用者數量開始，並慢慢增加到更多的使用者數量。
報告成功、錯誤和失敗
每一個腳本都必須定義一個方法來識別成功的互動以及失敗和錯誤樣式（錯誤完全不會有頁面回傳，而失敗可能在頁面上得到錯誤的資料）。
頁面顯示
如果負載測試程式可以讓您檢查一些發送給類比使用者的頁面，這會很有用，這樣您就可以確保測試工作是正確進行的。
匯出結果
您常常希望可以用不同的工具來分析測試結果，這些工具包括試算表和可以處理資料的自定義腳本。雖然許多負載測試工具包括大量的分析功能，但是匯出資料的能力使您在以任意的方式分析和編輯資料方面具有更大的靈活性。
考慮時間
真實世界的使用者不會在收到一頁後立即請求另一頁──一般在查看一頁和下一頁之間會有延遲。
考慮時間這個標準術語表示在腳本中加入延遲以更真實地模擬使用者行為。大多數負載測試程式支援根據統計分佈隨機產生考慮時間。
Client從列表中選擇資料
使用者一般不會使用同樣的一組資料，每位元使用者通常與伺服器進行不同的互動。模擬使用者應該也這樣做，如果在互動的關鍵點，腳本可以從一組資料中選擇資料，則可以更容易地讓您的模擬使用者表現出使用不同資料的行為。
從手動執行的session記錄腳本
相對於撰寫腳本，用瀏覽器手動執行session並記錄這個session然後再編輯會容易得多。
JavaScript
一些應用程式大量使用 JavaScript 並且需要類比Client支援它。不過，使用使用者端 JavaScript 可能會增加對測試系統上系統資源的需求。
分析工具
測量效能只是成功的一半。另一半是分析效能資料。誰能比撰寫測試工具的人能更好地開發這種分析工具呢？是的，至少理論是這樣。無論如何，您的工具箱提供的分析工具越多，您就能做得越好。
測量伺服器端統計數字
基本負載測試程式測量Client/伺服器互動中基於Client的回應時間。如果同時收集其他統計數位，如 CPU 使用情況和頁面錯誤率就更好了。您得到的統計數位越多，您用負載測試系統可以做的就越多。如果有這種資料，那麼就可以做一些有用的工作，如查看伺服器負載上下文中的Client回應時間和流量統計。
 |  |
結論
用任何一種工具可以完成的工作常常受到人的技能、知識和想像力的局限。在描述用負載測試工具查看什麼內容的時候，我們也展示了使用這種工具的各種可能性。現在，您可以運用您的想像力去開拓更多的可能性。
參考資料
作者簡介
對本文的評價
| 
