1樓：城兒
對於企業應用程式，有許多進行效能測試的方法，其中一些方法實行起來要比其他方法困難。所要進行的效能測試的型別取決於想要達到的結果。例如，對於可再現性，基準測試是最好的方法。
而要從當前使用者負載的角度測試系統的上限，則應該使用容量規劃測試。本文將介紹幾種設定和執行效能測試的方法，並討論這些方法的區別。
如果不進行合理的規劃，對j2ee應用程式進行效能測試將會是一項令人望而生畏且有些混亂的任務。因為對於任何的軟體開發流程，都必須收集需求、理解業務需要，並在進行實際測試之前設計出正式的進度表。效能測試的需求由業務需要驅動，並由一組用例闡明。
這些用例可以基於歷史資料（例如，伺服器一週的負載模式）或**的近似值。弄清楚需要測試的內容之後，就需要知道如何進行測試了。
在開發階段前期，應該使用基準測試來確定應用程式中是否出現效能倒退。基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是，每次測試改變一個且只改變一個引數。
例如，如果想知道增加jvm記憶體是否會影響應用程式的效能，就逐次遞增jvm記憶體（例如，從1024 mb增至1224 mb，然後是1524 mb，最後是2024 mb），在每個階段收集結果和環境資料，記錄資訊，然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麼是基準測試，以及執行基準測試的最佳引數。
開發階段後期，在應用程式中的bug已經被解決，應用程式達到一種穩定狀態之後，可以執行更為複雜的測試，確定系統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soak test)、峰谷測試（peak-rest test)，它們旨在通過測試應用程式的可靠性、健壯性和可伸縮性來測試接近於現實世界的場景。對於下面的描述應該從抽象的意義上理解，因為每個應用程式的使用模式都是不同的。
例如，容量規劃測試通常都使用較緩慢的ramp-up（下文有定義），但是如果應用程式在一天之中的某個時段中有快速突發的流量，那麼自然應該修改測試以反映這種情況。但是，要記住，因為更改了測試引數（比如ramp-up週期或使用者的考慮時間（think-time)），測試的結果肯定也會改變。一個不錯的方法是，執行一系列的基準測試，確立一個已知的可控環境，然後再對變化進行比較。
基準測試的關鍵是要獲得一致的、可再現的結果。可再現的結果有兩個好處：減少重新執行測試的次數；對測試的產品和產生的數字更為確信。
使用的效能測試工具可能會對測試結果產生很大影響。假定測試的兩個指標是伺服器的響應時間和吞吐量，它們會受到伺服器上的負載的影響。伺服器上的負載受兩個因素影響：
同時與伺服器通訊的連線（或虛擬使用者）的數目，以及每個虛擬使用者請求之間的考慮時間的長短。很明顯，與伺服器通訊的使用者越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。
這兩個因素的不同組合會產生不同的伺服器負載等級。記住，隨著伺服器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
注意，吞吐量以穩定的速度增長，然後在某一個點上穩定下來。
在某一點上，執行佇列開始增長，因為伺服器上所有的執行緒都已投入使用，傳入的請求不再被立即處理，而是放入佇列中，當執行緒空閒時再處理。
注意，最初的一段時間，執行佇列的長度為零，然後就開始以穩定的速度增長。這是因為系統中的負載在穩定增長，雖然最初系統有足夠的空閒執行緒去處理增加的負載，最終它還是不能承受，而必須將其排入佇列。
當系統達到飽和點，伺服器吞吐量保持穩定後，就達到了給定條件下的系統上限。但是，隨著伺服器負載的繼續增長，系統的響應時間也隨之延長，雖然吞吐量保持穩定。
注意，在執行佇列（圖2）開始增長的同時，響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。
為了獲得真正可再現的結果，應該將系統置於相同的高負載下。為此，與伺服器通訊的虛擬使用者應該將請求之間的考慮時間設為零。這樣伺服器會立即超載，並開始構建執行佇列。
如果請求（虛擬使用者）數保持一致，基準測試的結果應該會非常精確，完全可以再現。
您可能要問的一個問題是：「如何度量結果？」對於一次給定的測試，應該取響應時間和吞吐量的平均值。
精確地獲得這些值的唯一方法是一次載入所有的使用者，然後在預定的時間段內持續執行。這稱為「flat」測試。
與此相對應的是「ramp-up」測試。
ramp-up測試中的使用者是交錯上升的（每幾秒增加一些新使用者）。ramp-up測試不能產生精確和可重現的平均值，這是因為由於使用者的增加是每次一部分，系統的負載在不斷地變化。因此，flat執行是獲得基準測試資料的理想模式。
這不是在貶低ramp-up測試的價值。實際上，ramp-up測試對找出以後要執行的flat測試的範圍非常有用。ramp-up測試的優點是，可以看出隨著系統負載的改變，測量值是如何改變的。
然後可以據此選擇以後要執行的flat測試的範圍。
flat測試的問題是系統會遇到「波動」效果。
注意波動的出現，吞吐量不再是平滑的。
這在系統的各個方面都有所體現，包括cpu的使用量。
注意，每隔一段時間就會出現一個波形。cpu使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。
此外，執行佇列也承受著不穩定的負載，因此可以看到，隨著系統負載的增加和減少，執行佇列也在增長和縮減。
注意，每隔一段時間就會出現一個波形。執行佇列曲線與上面的cpu使用量圖非常相似。
最後，系統中事務的響應時間也遵循著這個波動模式。
注意，每隔一段時間就會出現一個波形。事務的響應時間也與上面的圖類似，只不過其效果隨著時間的推移逐漸減弱。
當測試中所有的使用者都同時執行幾乎相同的操作時，就會發生這種現象。這將會產生非常不可靠和不精確的結果，所以必須採取一些措施防止這種情況的出現。有兩種方法可以從這種型別的結果中獲得精確的測量值。
如果測試可以執行相當長的時間（有時是幾個小時，取決於使用者的操作持續的時間），最後由於隨機事件的本性使然，伺服器的吞吐量會被「拉平」。或者，可以只選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲資料的時間非常短。
對於效能規劃型別的測試來說，其目標是找出，在特定的環境下，給定應用程式的效能可以達到何種程度。此時可重現性就不如在基準測試中那麼重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了儘量模擬具有真實使用者負載的現實世界應用程式。
通常，具體的目標是找出系統在特定的伺服器響應時間下支援的當前使用者的最大數。例如，您可能想知道：如果要以5秒或更少的響應時間支援8,000個當前使用者，需要多少個伺服器？
要回答這個問題，需要知道系統的更多資訊。
要確定系統的容量，需要考慮幾個因素。通常，伺服器的使用者總數非常大（以十萬計），但是實際上，這個數字並不能說明什麼。真正需要知道的是，這些使用者中有多少是併發與伺服器通訊的。
其次要知道的是，每個使用者的「考慮時間」即請求間時間是多少。這非常重要，因為考慮時間越短，系統所能支援的併發使用者越少。例如，如果使用者的考慮時間是1秒，那麼系統可能只能支援數百個這樣的併發使用者。
但是，如果使用者的考慮時間是30秒，那麼系統則可能支援數萬個這樣的併發使用者（假定硬體和應用程式都是相同的）。在現實世界中，通常難以確定使用者的確切考慮時間。還要注意，在現實世界中，使用者不會精確地按照間隔時間發出請求。
於是就引入了隨機性。如果知道普通使用者的考慮時間是5秒，誤差為20%，那麼在設計負載測試時，就要確保請求間的時間為5×（1 +/- 20%）秒。此外，可以利用「調步」的理念向負載場景中引入更多的隨機性。
它是這樣的：在一個虛擬使用者完成一整套的請求後，該使用者暫停一個設定的時間段，或者一個小的隨機時間段（例如，2×（1 +/- 25%）秒），然後再繼續執行下一套請求。將這兩種隨機化方法運用到測試中，可以提供更接近於現實世界的場景。
進行實際的容量規劃測試了。接下來的問題是：如何載入使用者以模擬負載狀態？
最好的方法是模擬高峰時間使用者與伺服器通訊的狀況。這種使用者負載狀態是在一段時間內逐步達到的嗎？如果是，應該使用ramp-up型別的測試，每隔幾秒增加x個使用者。
或者，所有使用者是在一個非常短的時間內同時與系統通訊？如果是這樣，就應該使用flat型別的測試，將所有的使用者同時載入到伺服器。兩種不同型別的測試會產生沒有可比性的不同測試。
例如，如果進行ramp-up型別的測試，系統可以以4秒或更短的響應時間支援5,000個使用者。而執行flat測試，您會發現，對於5,000個使用者，系統的平均響應時間要大於4秒。這是由於ramp-up測試固有的不準確性使其不能顯示系統可以支援的併發使用者的精確數字。
以門戶應用程式為例，隨著門戶規模的擴大和叢集規模的擴大，這種不確定性就會隨之顯現。
這不是說不應該使用ramp-up測試。對於系統負載在一段比較長的時間內緩慢增加的情況，ramp-up測試效果還是不錯的。這是因為系統能夠隨著時間不斷調整。
如果使用快速ramp-up測試，系統就會滯後，從而報告一個較相同使用者負載的flat測試低的響應時間。那麼，什麼是確定容量的最好方法？結合兩種負載型別的優點，並執行一系列的測試，就會產生最好的結果。
例如，首先使用ramp-up測試確定系統可以支援的使用者範圍。確定了範圍之後，以該範圍內不同的併發使用者負載進行一系列的flat測試，更精確地確定系統的容量。 滲入測試是一種比較簡單的效能測試。
滲入測試所需時間較長，它使用固定數目的併發使用者測試系統的總體健壯性。這些測試將會通過記憶體洩漏、增加的垃圾收集（gc)或系統的其他問題，顯示因長時間執行而出現的任何效能降低。測試執行的時間越久，您對系統就越瞭解。
執行兩次測試是一個好主意——一次使用較低的使用者負載（要在系統容量之下，以便不會出現執行佇列），一次使用較高的負載（以便出現積極的執行佇列）。
測試應該執行幾天的時間，以便真正瞭解應用程式的長期健康狀況。要確保測試的應用程式儘可能接近現實世界的情況，使用者場景也要逼真（虛擬使用者通過應用程式導航的方式要與現實世界一致），從而測試應用程式的全部特性。確保執行了所有必需的監控工具，以便精確地監測並跟蹤問題。
峰谷測試兼有容量規劃ramp-up型別測試和滲入測試的特徵。其目標是確定從高負載（例如系統高峰時間的負載）恢復、轉為幾乎空閒、然後再攀升到高負載、再降低的能力。
實現這種測試的最好方法就是，進行一系列的快速ramp-up測試，繼之以一段時間的平穩狀態（取決於業務需求），然後急劇降低負載，此時可以令系統平息一下，然後再進行快速的ramp-up；反覆重複這個過程。這樣可以確定以下事項：第二次高峰是否重現第一次的峰值？
其後的每次高峰是等於還是大於第一次的峰值？在測試過程中，系統是否顯示了記憶體或gc效能降低的有關跡象？測試執行（不停地重複「峰值/空閒」週期）的時間越長，您對系統的長期健康狀況就越瞭解。
測試電腦效能的軟體，測試電腦效能用什麼軟體
常用的比較專業bai 可靠的系統硬體性du能測試工具 zhi，還是建dao議使用3dmark和pcmark這兩個回工答具。這兩個工具都是老牌的硬體測試工具廠商futuremark的產品，其中前者專用於測試顯示卡的遊戲效能，而後者常用於測試整機的系統效能。應該說，它們的測試結果比較權威，可靠和科學，一...
耐候老化效能測試要做哪些專案
耐候老化性bai能測試 快速紫外老du化測試 astm zhiaatcc,iso,sae j,en,bs,gb t氙燈老dao化 sae j,astm,iso,gb t,pv,ul碳弧專光老化 astm,jis d 臭氧老化 astm,iso,gb t 低溫實屬驗 iec,bs en,gb 熱空氣老...
關於WINDOWS7下魯大師測試顯示卡效能的問題
win7系統下，cpu和gpu的工作是相互協同的，windows 7的核心組成部分已經包括了gpu 圖形處理器 計算，gpu不再僅用於圖形。在windows7中，cpu與gpu組成了協同處理環境。cpu運算非常複雜的序列 而gpu則執行大規模並行應用程式。因此，安裝windows7的電腦cpu與gp...