性能測試方法
 對于企業(yè)應(yīng)用程序，有許多進行性能測試的方法，其中一些方法實行起來要比其他方法困難。所要進行的性能測試的類型取決于想要達到的結(jié)果。例如，對于可再現(xiàn)性，基準測試是最好的方法。而要從當前用戶負載的角度測試系統(tǒng)的上限，則應(yīng)該使用容量規(guī)劃測試。本文將介紹幾種設(shè)置和運行性能測試的方法，并討論這些方法的區(qū)別。 簡介 如果不進行合理的規(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é)果?？稍佻F(xiàn)的結(jié)果有兩個好處：減少重新運行測試的次數(shù)；對測試的產(chǎn)品和產(chǎn)生的數(shù)字更為確信。使用的性能測試工具可能會對測試結(jié)果產(chǎn)生很大影響。假定測試的兩個指標是服務(wù)器的響應(yīng)時間和吞吐量，它們會受到服務(wù)器上的負載的影響。服務(wù)器上的負載受兩個因素影響：同時與服務(wù)器通信的連接（或虛擬用戶）的數(shù)目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務(wù)器通信的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會產(chǎn)生不同的服務(wù)器負載等級。記住，隨著服務(wù)器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
注意，吞吐量以穩(wěn)定的速度增長，然后在某一個點上穩(wěn)定下來。 在某一點上，執(zhí)行隊列開始增長，因為服務(wù)器上所有的線程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當線程空閑時再處理。
注意，最初的一段時間，執(zhí)行隊列的長度為零，然后就開始以穩(wěn)定的速度增長。這是因為系統(tǒng)中的負載在穩(wěn)定增長，雖然最初系統(tǒng)有足夠的空閑線程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。 當系統(tǒng)達到飽和點，服務(wù)器吞吐量保持穩(wěn)定后，就達到了給定條件下的系統(tǒng)上限。但是，隨著服務(wù)器負載的繼續(xù)增長，系統(tǒng)的響應(yīng)時間也隨之延長，雖然吞吐量保持穩(wěn)定。
注意，在執(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”測試。
與此相對應(yīng)的是“ramp-up”測試。
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)會遇到“波動”效果。
注意波動的出現(xiàn)，吞吐量不再是平滑的。 這在系統(tǒng)的各個方面都有所體現(xiàn)，包括CPU的使用量。
注意，每隔一段時間就會出現(xiàn)一個波形。CPU使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。 此外，執(zhí)行隊列也承受著不穩(wěn)定的負載，因此可以看到，隨著系統(tǒng)負載的增加和減少，執(zhí)行隊列也在增長和縮減。
注意，每隔一段時間就會出現(xiàn)一個波形。執(zhí)行隊列曲線與上面的CPU使用量圖非常相似。 最后，系統(tǒng)中事務(wù)的響應(yīng)時間也遵循著這個波動模式。
注意，每隔一段時間就會出現(xiàn)一個波形。事務(wù)的響應(yīng)時間也與上面的圖類似，只不過其效果隨著時間的推移逐漸減弱。 當測試中所有的用戶都同時執(zhí)行幾乎相同的操作時，就會發(fā)生這種現(xiàn)象。這將會產(chǎn)生非常不可靠和不精確的結(jié)果，所以必須采取一些措施防止這種情況的出現(xiàn)。有兩種方法可以從這種類型的結(jié)果中獲得精確的測量值。如果測試可以運行相當長的時間（有時是幾個小時，取決于用戶的操作持續(xù)的時間），最后由于隨機事件的本性使然，服務(wù)器的吞吐量會被“拉平”。或者，可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數(shù)據(jù)的時間非常短。 性能規(guī)劃測試 對于性能規(guī)劃類型的測試來說，其目標是找出，在特定的環(huán)境下，給定應(yīng)用程序的性能可以達到何種程度。此時可重現(xiàn)性就不如在基準測試中那么重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現(xiàn)實世界應(yīng)用程序。通常，具體的目標是找出系統(tǒng)在特定的服務(wù)器響應(yīng)時間下支持的當前用戶的最大數(shù)。例如，您可能想知道：如果要以5秒或更少的響應(yīng)時間支持8,000個當前用戶，需要多少個服務(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)的長期健康狀況就越了解。 結(jié)束語 本文介紹了進行性能測試的幾種方法。取決于業(yè)務(wù)需求、開發(fā)周期和應(yīng)用程序的生命周期，對于特定的企業(yè)，某些測試會比其他的更適合。但是，對于任何情況，在決定進行某一種測試前，都應(yīng)該問自己一些基本問題。這些問題的答案將會決定哪種測試方法是最好的。 這些問題包括：
將這些問題的答案與上述性能測試類型相對照，應(yīng)該就可以制定出測試應(yīng)用程序的總體性能的完美計劃。 參考資料
原文出處 http://dev2dev./pub/a/2005/09/performance_testing.html 
|
|||||||
|
|
來自： bluecrystal > 《軟件測試》
