簡介
如果不進行合理的規(guī)劃，對
J2EE
應(yīng)用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務(wù)。因為對于任何的軟件開發(fā)流程，都必須收集需求、理解業(yè)務(wù)需要，并在進行實際測試之前設(shè)計出正式的進度表。性能測試的需求由業(yè)務(wù)需要驅(qū)動，并由一組用例闡明。這些用例可以基于歷史數(shù)據(jù)（例如，服務(wù)器一周的負載模式）或預(yù)測的近似值。弄清楚需要測試的內(nèi)容之后，就需要知道如何進行測試了。
在開發(fā)階段前期，應(yīng)該使用基準測試來確定應(yīng)用程序中是否出現(xiàn)性能倒退。基準測試可以在一個相對短的時間內(nèi)收集可重復(fù)的結(jié)果。進行基準測試的最好方法是，每次測試改變一個且只改變一個參數(shù)。例如，如果想知道增加
JVM
內(nèi)存是否會影響應(yīng)用程序的性能，就逐次遞增
JVM
內(nèi)存（例如，從
1024 MB
增至
1224 MB
，然后是
1524 MB
，最后是
2024 MB
），在每個階段收集結(jié)果和環(huán)境數(shù)據(jù)，記錄信息，然后轉(zhuǎn)到下一階段。這樣在分析測試結(jié)果時就有跡可循。下一小節(jié)我將介紹什么是基準測試，以及運行基準測試的最佳參數(shù)。
開發(fā)階段后期，在應(yīng)用程序中的
bug
已經(jīng)被解決，應(yīng)用程序達到一種穩(wěn)定狀態(tài)之后，可以運行更為復(fù)雜的測試，確定系統(tǒng)在不同的負載模式下的表現(xiàn)。這些測試被稱為容量規(guī)劃測試、滲入測試
(soak test)
、峰谷測試
(peak-rest test)
，它們旨在通過測試應(yīng)用程序的可靠性、健壯性和可伸縮性來測試接近于現(xiàn)實世界的場景。對于下面的描述應(yīng)該從抽象的意義上理解，因為每個應(yīng)用程序的使用模式都是不同的。例如，容量規(guī)劃測試通常都使用較緩慢的
ramp-up
（下文有定義），但是如果應(yīng)用程序在一天之中的某個時段中有快速突發(fā)的流量，那么自然應(yīng)該修改測試以反映這種情況。但是，要記住，因為更改了測試參數(shù)（比如
ramp-up
周期或用戶的考慮時間
(think-time)
），測試的結(jié)果肯定也會改變。一個不錯的方法是，運行一系列的基準測試，確立一個已知的可控環(huán)境，然后再對變化進行比較。
基準測試
基準測試的關(guān)鍵是要獲得一致的、可再現(xiàn)的結(jié)果。可再現(xiàn)的結(jié)果有兩個好處：減少重新運行測試的次數(shù)；對測試的產(chǎn)品和產(chǎn)生的數(shù)字更為確信。使用的性能測試工具可能會對測試結(jié)果產(chǎn)生很大影響。假定測試的兩個指標是服務(wù)器的響應(yīng)時間和吞吐量，它們會受到服務(wù)器上的負載的影響。服務(wù)器上的負載受兩個因素影響：同時與服務(wù)器通信的連接（或虛擬用戶）的數(shù)目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務(wù)器通信的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會產(chǎn)生不同的服務(wù)器負載等級。記住，隨著服務(wù)器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
圖
1.
隨著負載的增加，系統(tǒng)吞吐量的曲線（單位：頁面
/
秒）
注意，吞吐量以穩(wěn)定的速度增長，然后在某一個點上穩(wěn)定下來。
在某一點上，執(zhí)行隊列開始增長，因為服務(wù)器上所有的線程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當(dāng)線程空閑時再處理。
?
圖
2.
隨著負載的增加，系統(tǒng)執(zhí)行隊列長度的曲線
注意，最初的一段時間，執(zhí)行隊列的長度為零，然后就開始以穩(wěn)定的速度增長。這是因為系統(tǒng)中的負載在穩(wěn)定增長，雖然最初系統(tǒng)有足夠的空閑線程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。
當(dāng)系統(tǒng)達到飽和點，服務(wù)器吞吐量保持穩(wěn)定后，就達到了給定條件下的系統(tǒng)上限。但是，隨著服務(wù)器負載的繼續(xù)增長，系統(tǒng)的響應(yīng)時間也隨之延長，雖然吞吐量保持穩(wěn)定。
?
圖
3.
隨著負載的增加，系統(tǒng)中兩個事務(wù)的響應(yīng)時間曲線
注意，在執(zhí)行隊列（圖
2
）開始增長的同時，響應(yīng)時間也開始以遞增的速度增長。這是因為請求不能被及時處理。
為了獲得真正可再現(xiàn)的結(jié)果，應(yīng)該將系統(tǒng)置于相同的高負載下。為此，與服務(wù)器通信的虛擬用戶應(yīng)該將請求之間的考慮時間設(shè)為零。這樣服務(wù)器會立即超載，并開始構(gòu)建執(zhí)行隊列。如果請求（虛擬用戶）數(shù)保持一致，基準測試的結(jié)果應(yīng)該會非常精確，完全可以再現(xiàn)。
您可能要問的一個問題是：
“
如何度量結(jié)果？
”
對于一次給定的測試，應(yīng)該取響應(yīng)時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然后在預(yù)定的時間段內(nèi)持續(xù)運行。這稱為
“flat”
測試。
圖
4. flat
測試的情況（所有的用戶都是同時加載的）
與此相對應(yīng)的是
“ramp-up”
測試。
?
圖
5. ramp-up
測試的情況（在測試期間，用戶以穩(wěn)定速度（每秒
x
個）增加）
ramp-up
測試中的用戶是交錯上升的（每幾秒增加一些新用戶）。
ramp-up
測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因為由于用戶的增加是每次一部分，系統(tǒng)的負載在不斷地變化。因此，
flat
運行是獲得基準測試數(shù)據(jù)的理想模式。
這不是在貶低
ramp-up
測試的價值。實際上，
ramp-up
測試對找出以后要運行的
flat
測試的范圍非常有用。
ramp-up
測試的優(yōu)點是，可以看出隨著系統(tǒng)負載的改變，測量值是如何改變的。然后可以據(jù)此選擇以后要運行的
flat
測試的范圍。
Flat
測試的問題是系統(tǒng)會遇到
“
波動
”
效果。
?
?
圖
6.
一次
flat
測試中所測得的系統(tǒng)吞吐量的曲線（單位：頁面
/
秒）
注意波動的出現(xiàn)，吞吐量不再是平滑的。
這在系統(tǒng)的各個方面都有所體現(xiàn)，包括
CPU
的使用量。
?
圖
7.
一次
flat
測試中所測得的系統(tǒng)
CPU
使用量隨時間變化的曲線
注意，每隔一段時間就會出現(xiàn)一個波形。
CPU
使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。
此外，執(zhí)行隊列也承受著不穩(wěn)定的負載，因此可以看到，隨著系統(tǒng)負載的增加和減少，執(zhí)行隊列也在增長和縮減。
?
圖
8.
一次
flat
測試中所測得的系統(tǒng)執(zhí)行隊列的曲線
注意，每隔一段時間就會出現(xiàn)一個波形。執(zhí)行隊列曲線與上面的
CPU
使用量圖非常相似。
最后，系統(tǒng)中事務(wù)的響應(yīng)時間也遵循著這個波動模式。
?
圖
9.
一次
flat
測試中所測得的系統(tǒng)事務(wù)的響應(yīng)時間
注意，每隔一段時間就會出現(xiàn)一個波形。事務(wù)的響應(yīng)時間也與上面的圖類似，只不過其效果隨著時間的推移逐漸減弱。
當(dāng)測試中所有的用戶都同時執(zhí)行幾乎相同的操作時，就會發(fā)生這種現(xiàn)象。這將會產(chǎn)生非常不可靠和不精確的結(jié)果，所以必須采取一些措施防止這種情況的出現(xiàn)。有兩種方法可以從這種類型的結(jié)果中獲得精確的測量值。如果測試可以運行相當(dāng)長的時間（有時是幾個小時，取決于用戶的操作持續(xù)的時間），最后由于隨機事件的本性使然，服務(wù)器的吞吐量會被
“
拉平
”
。或者，可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數(shù)據(jù)的時間非常短。
性能規(guī)劃測試
對于性能規(guī)劃類型的測試來說，其目標是找出，在特定的環(huán)境下，給定應(yīng)用程序的性能可以達到何種程度。此時可重現(xiàn)性就不如在基準測試中那么重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現(xiàn)實世界應(yīng)用程序。通常，具體的目標是找出系統(tǒng)在特定的服務(wù)器響應(yīng)時間下支持的當(dāng)前用戶的最大數(shù)。例如，您可能想知道：如果要以
5
秒或更少的響應(yīng)時間支持
8,000
個當(dāng)前用戶，需要多少個服務(wù)器？要回答這個問題，需要知道系統(tǒng)的更多信息。
要確定系統(tǒng)的容量，需要考慮幾個因素。通常，服務(wù)器的用戶總數(shù)非常大（以十萬計），但是實際上，這個數(shù)字并不能說明什么。真正需要知道的是，
這些用戶中有多少是并發(fā)與服務(wù)器通信的
。其次要知道的是，
每個用戶的
“
考慮時間
”
即請求時間是多少
。這非常重要，
因為考慮時間越短，系統(tǒng)所能支持的并發(fā)用戶越少
。例如，如果用戶的考慮時間是
1
秒，那么系統(tǒng)可能只能支持數(shù)百個這樣的并發(fā)用戶。但是，如果用戶的考慮時間是
30
秒，那么系統(tǒng)則可能支持數(shù)萬個這樣的并發(fā)用戶（假定硬件和應(yīng)用程序都是相同的）。在現(xiàn)實世界中，通常難以確定用戶的確切考慮時間。還要注意，在現(xiàn)實世界中，用戶不會精確地按照間隔時間發(fā)出請求。
于是就引入了隨機性。如果知道普通用戶的考慮時間是
5
秒，誤差為
20%
，那么在設(shè)計負載測試時，就要確保請求間的時間為
5×
（
1 +/- 20%
）秒。此外，可以利用
“
調(diào)步
”
的理念向負載場景中引入更多的隨機性。它是這樣的：在一個虛擬用戶完成一整套的請求后，該用戶暫停一個設(shè)定的時間段，或者一個小的隨機時間段（例如，
2×
（
1 +/- 25%
）秒），然后再繼續(xù)執(zhí)行下一套請求。將這兩種隨機化方法運用到測試中，可以提供更接近于現(xiàn)實世界的場景。
現(xiàn)在該進行實際的容量規(guī)劃測試了。接下來的問題是：
如何加載用戶以模擬負載狀態(tài)？
最好的方法是模擬在高峰時間用戶與服務(wù)器通信的狀況
。這種用戶負載狀態(tài)是在一段時間內(nèi)逐步達到的嗎？如果是，應(yīng)該使用
ramp-up
類型的測試，每隔幾秒增加
x
個用戶。或者，所有用戶是在一個非常短的時間內(nèi)同時與系統(tǒng)通信？如果是這樣，就應(yīng)該使用
flat
類型的測試，將所有的用戶同時加載到服務(wù)器。兩種不同類型的測試會產(chǎn)生沒有可比性的不同測試。例如，如果進行
ramp-up
類型的測試，系統(tǒng)可以以
4
秒或更短的響應(yīng)時間支持
5,000
個用戶。而執(zhí)行
flat
測試，您會發(fā)現(xiàn)，對于
5,000
個用戶，系統(tǒng)的平均響應(yīng)時間要大于
4
秒。這是由于
ramp-up
測試固有的不準確性使其不能顯示系統(tǒng)可以支持的并發(fā)用戶的精確數(shù)字。以門戶應(yīng)用程序為例，隨著門戶規(guī)模的擴大和集群規(guī)模的擴大，這種不確定性就會隨之顯現(xiàn)。
這不是說不應(yīng)該使用
ramp-up
測試。對于系統(tǒng)負載在一段比較長的時間內(nèi)緩慢增加的情況，
ramp-up
測試效果還是不錯的。這是因為系統(tǒng)能夠隨著時間不斷調(diào)整。如果使用快速
ramp-up
測試，系統(tǒng)就會滯后，從而報告一個較相同用戶負載的
flat
測試低的響應(yīng)時間。那么，什么是確定容量的最好方法？結(jié)合兩種負載類型的優(yōu)點，并運行一系列的測試，就會產(chǎn)生最好的結(jié)果。例如，
首先使用
ramp-up
測試確定系統(tǒng)可以支持的用戶范圍。確定了范圍之后，以該范圍內(nèi)不同的并發(fā)用戶負載進行一系列的
flat
測試，更精確地確定系統(tǒng)的容量。
滲入測試
滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長，它使用固定數(shù)目的并發(fā)用戶測試系統(tǒng)的總體健壯性。這些測試將會通過內(nèi)存泄漏、增加的垃圾收集
(GC)
或系統(tǒng)的其他問題，顯示因長時間運行而出現(xiàn)的任何性能降低。測試運行的時間越久，您對系統(tǒng)就越了解。運行兩次測試是一個好主意
——
一次使用較低的用戶負載（要在系統(tǒng)容量之下，以便不會出現(xiàn)執(zhí)行隊列），一次使用較高的負載（以便出現(xiàn)積極的執(zhí)行隊列）。
測試應(yīng)該運行幾天的時間，以便真正了解應(yīng)用程序的長期健康狀況。要確保測試的應(yīng)用程序盡可能接近現(xiàn)實世界的情況，用戶場景也要逼真（虛擬用戶通過應(yīng)用程序?qū)Ш降姆绞揭c現(xiàn)實世界一致），從而測試應(yīng)用程序的全部特性。確保運行了所有必需的監(jiān)控工具，以便精確地監(jiān)測并跟蹤問題。
峰谷測試
峰谷測試兼有容量規(guī)劃
ramp-up
類型測試和滲入測試的特征。其目標是
確定從高負載（例如系統(tǒng)高峰時間的負載）恢復(fù)、轉(zhuǎn)為幾乎空閑、然后再攀升到高負載、再降低的能力
。
實現(xiàn)這種測試的最好方法就是，進行一系列的快速
ramp-up
測試，繼之以一段時間的平穩(wěn)狀態(tài)（取決于業(yè)務(wù)需求），然后急劇降低負載，此時可以令系統(tǒng)平息一下，然后再進行快速的
ramp-up
；反復(fù)重復(fù)這個過程。這樣可以確定以下事項：第二次高峰是否重現(xiàn)第一次的峰值？其后的每次高峰是等于還是大于第一次的峰值？在測試過程中，系統(tǒng)是否顯示了內(nèi)存或
GC
性能降低的有關(guān)跡象？測試運行（不停地重復(fù)
“
峰值
/
空閑
”
周期）的時間越長，您對系統(tǒng)的長期健康狀況就越了解。