性能測試容量計算方法

　　關于性能測試，你可能會比較關心將系統從超負荷運行中解救出來所需要的時間。

　　我們先來介紹幾種性能測試的類型。

　　容量測試主要關心的是我們在系統容量達到什么程度的時候需要增加系統的資源以增加可支持用戶量(注：也就是確定系統可處理同時在線的最大用戶數)

　　負載測試為IT系統提供了一種量化其在真實環境下承受能力的的方法，便于檢驗當前所提供的IT資源能否承受預期給出的性能指標。(注：測試數據在超負荷環境下運行，程序能否承擔)

　　壓力測試則關心的是一個系統所能承受的最大的負載情況。(~我還是沒看大懂他們之間很明顯的區別……)

　　系統的可承受負載一般認為是當用戶發現反應時間變慢的時候的負載值，這個值一般需要通過性能測試來獲得。

　　當前負載(當前實際需求)和負載測試中得到的負載數據的差值就是系統給用戶預留的負載儲備--即“峰值儲備”，以應對客戶負載增加及處理用戶負載變化等

　　負載平衡管理器的主要任務就是處理那些空閑的線程占用資源的等問題，以避免因系統資源不足導致嚴重后果。

　　如果我們有一個比較好的計劃并且有過試驗經驗的話(這需要有一個時間表來計劃這一系列活動)，升級系統將變得比較順利。

　　我們可以這樣估計系統資源什么時候被耗盡：分析當前系統可用資源量以及系統資源被蠶食的速率(一般我們是以天為單位來計算的)，我們還要跟蹤系統資源變化(以天為單位)以估計我們什么時候應該開始增加系統資源的工作。

　　跟蹤系統的反應時間(接收請求到發出響應的總時間)，當這個時間達到某個值的時候我們也需要進行相應的處理或者增加系統資源

　　下面這張表給出的是一個需要進行這種處理的例子，我們將對它進行一個分析

　　計算方法示例

　　1 一項對以前文檔的分析結果顯示，某系統目前每小時處理300 000頁面元素請求，如果按照每個頁面平均10個頁面元素來算的話，就是系統每小時處理30 000個頁面

　　2另外一項分析表明每個用戶處理事務平均為三個頁面，也就是說現在我們每小時需要處理10 000個用戶事務請求

　　3 市場部的調研指出一年之后我們的用戶負載將要增加一倍，也就是說我們在那個時候每小時需要處理600 000個頁面元素的請求，或者說60 000個頁面請求，也就是20 000個用戶事務處理

　　這樣算來，負載的增加量就是60 000頁面請求-30 000頁面請求(現在)=30 000個頁面請求每小時平均每天的負載增加率就是100%/365=2.74%， 每天需要多處理30 000*2.74%=82.2個頁面請求(假設用戶的負載增長是線性的)。

　　4 當前的負載測試運行結果表明，我們的系統每小時最多處理60 000個頁面請求，如果頁面請求數超過這一數值的話就會導致系統出現問題，另一方面，當頁面請求達到50 000個每小時的時候，反應時間就會開始降低。

　　為得到可用系統資源數據，我們需要做一個減法，50 000-30 000=20 000個頁面每小時，也就是說現在系統的資源還可以支持20 000個頁面請求(每小時)

　　用這個數據除以82.2我們知道我們的系統還可以保證(20 000/82.2=)243天在正常的負載條件下運行

　　5 另外一個碰頭會議告訴我們大概需要40天的時間用于安排，升級設備，安裝，部署，測試等等一系列的活動之后才可以成功升級我們的系統，這還是在一切順利的時候，如果算上緩沖時間，我們就需要在再加上十天的時間。(注：指作者進行的項目)

　　這也就是說我們至少需要在系統達到資源支持極限狀態五十天前開始對我們的系統進行升級。

　　如果我們的估計足夠準確的話，我們就需要在(243-50=)193天之后開始進行系統的升級。

　　在進行系統升級的過程中(50天時間里)，預期的工作負載增長超過50天*82.2每天=4110個頁面請求每小時

　　這樣向前推斷的話，我們開始處理工作負載問題的時間就是當工作負載達到50 000-4110=45890個頁面請求每小時的時候

原文轉自：http://www.uml.org.cn/Test/200812257.asp