web效能測試基本效能指標

Web效能測試的部分概況一般來說，一個Web請求的處理包括以下步驟：

（1）客戶發送請求

（2）web server 接受到請求，進行處理；

（3）web server 向DB擷取資料；

（4）web server產生使用者的object(頁面)，返回給使用者。給客戶發送請求開始到最後一個位元組的時間稱為回應時間（第三步不包括在每次請求處理中）。

1.事務（Transaction）

在web效能測試中，一個事務表示一個“從使用者發送請求->web server接受到請求，進行處理-> web server向DB擷取資料->產生使用者的object(頁面)，返回給使用者”的過程，一般的回應時間都是針對事務而言的。

2.請求回應時間

請求回應時間指的是從用戶端發起的一個請求開始，到用戶端接收到從伺服器端返回的響應結束，這個過程所耗費的時間，在某些工具中，響應通常會稱為“TTLB”，即"time to last byte"，意思是從發起一個請求開始，到用戶端接收到最後一個位元組的響應所耗費的時間，回應時間的單位一般為“秒”或者“毫秒”。一個公式可以表示：回應時間＝網路回應時間+應用程式回應時間。標準可參考國外的3/5/10原則：

（1）在3秒鐘之內，頁面給予使用者響應並有所顯示，可認為是“很不錯的”；

（2）在3~5秒鐘內，頁面給予使用者響應並有所顯示，可認為是“好的”；

（3）在5~10秒鐘內，頁面給予使用者響應並有所顯示，可認為是“勉強接受的”；

（4）超過10秒就讓人有點不耐煩了，使用者很可能不會繼續等待下去；

3、事務回應時間

  事務可能由一系列請求組成,事務的回應時間主要是針對使用者而言,屬於宏觀上的概念，是為了向使用者說明業務回應時間而提出的.例如:跨行取款事務的回應時間就是由一系列的請求組成的.事務回應時間是直接衡量系統效能的參數.

4.並發使用者數

並發一般分為2種情況。一種是嚴格意義上的並發，即所有的使用者在同一時刻做同一件事情或者操作，這種操作一般指做同一類型的業務。比如在信用卡審批業務中，一定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即所有使用者進行完全一樣的 操作，例如在信用卡審批業務中，所有的使用者可以一起申請業務，或者修改同一條記錄。

　　另外一種並發是廣義範圍的並發。這種並發與前一種並發的區別是，儘管多個使用者對系統發出了請求或者進行了操作，但是這些請求或者操作可以是相同的，也可以是不同的。對整個系統而言，仍然是有很多使用者同時對系統進行操作，因此也屬於並發的範疇。

　　可以看出，後一種並發是包含前一種並發的。而且後一種並發更接近使用者的實際使用方式，因此對於大多數的系統，只有數量很少的使用者進行“嚴格意義上的並發”。對於WEB效能測試而言，這2種並發情況一般都需要進行測試，通常做法是先進行嚴格意義上的並發測試。嚴格意義上的使用者並發一般發生在使用比較頻繁的模組中，儘管發生的機率不是很大，但是一旦發生效能問題，後果很可能是致命的。嚴格意義上的並發測試往往和功能測試關聯起來，因為並發功能遇到異常通常都是程式問題，這種測試也是健壯性和穩定性測試的一部分。

使用者並發數量：關於使用者並發的數量，有2種常見的錯誤觀點。 一種錯誤觀點是把並發使用者數量理解為使用系統的全部使用者的數量，理由是這些使用者可能同時使用系統；還有一種比較接近正確的觀點是把線上使用者數量理解為並發使用者數量。實際上線上使用者也不一定會和其他使用者發生並發，例如正在瀏覽網頁的使用者，對伺服器沒有任何影響，但是，線上使用者數量是計算並發使用者數量的主要依據之一。

5.輸送量

指的是在一次效能測試過程中網路上傳輸的資料量的總和.輸送量/傳輸時間,就是吞吐率.

6、　TPS（transaction per second）

每秒鐘系統能夠處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.

7、點擊率

每秒鐘使用者向WEB伺服器提 交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"要求-回應"模式,使用者發出一次申請,伺服器就要處理一次,所以點擊是WEB應用能夠處理的交易的最小單位.如果把每次點擊定義為一個交易,點擊率和TPS就是一個概念.容易看出,點擊率越大,對伺服器的壓力越大.點擊率只是一個效能參考指標,重要的是分析點擊時產生的影響。需要注意的是,這裡的點擊並非指滑鼠的一次單擊操作,因為在一次單擊操作中,用戶端可能向伺服器發出多個HTTP請求.

8.資源使用率

指的是對不同的系統資源的使用程度,例如伺服器的CPU利用率,磁碟利用率等.資源使用率是分析系統效能指標進而改善效能的主要依據,因此是WEB效能測試工作的重點.

資源使用率主要針對WEB伺服器,作業系統,資料庫伺服器,網路等,是測試和分析瓶頸的主要參考.在WEB效能測試中,更根據需要採集相應的參數進行分析。

通用指標（指Web應用伺服器、資料庫伺服器必需測試項)

指標	說明
ProcessorTime	伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和
Memory Available Mbyte	可用記憶體數，如果測試時發現記憶體有變化情況也要注意，如果是記憶體泄露則比較嚴重
Physicsdisk Time	物理磁碟讀寫時間情況

Web伺服器指標

指標	說明
Requests Per Second（Avg Rps）	平均每秒鐘響應次數＝總請求時間 / 秒數
Avg time to last byte per terstion （mstes）	平均每秒業務指令碼的迭代次數 ,有人會把上面那個混淆
Successful Rounds	成功的請求
Failed Requests	失敗的請求
Successful Hits	成功的點擊次數
Failed Hits	失敗的點擊次數
Hits Per Second	每秒點擊次數
Successful Hits Per Second	每秒成功的點擊次數
Failed Hits Per Second	每秒失敗的點擊次數
Attempted Connections	嘗試連結數

資料庫伺服器效能指標

指標	說明
User 0 Connections	使用者串連數，也就是資料庫的串連數量
Number of deadlocks	資料庫死結
Butter Cache hit	資料庫Cache的命中情況

系統的瓶頸定義

效能項	命令	指標
CPU限制	vmstat	當%user+%sys超過80%時
磁碟I/O限制	Vmstat	當%iowait超過40%(AIX4.3.3或更高版本)時
應用磁碟限制	Iostat	當%tm_act超過70%時
虛存空間少	Lsps，-a	當分頁空間的活動率超過70%時
換頁限制	Iostat, stat	虛存邏輯卷%tm_act超過I/O(iostat)的30%，啟用的虛存率超過CPU數量(vmstat)的10倍時
系統失效	Vmstat, sar	頁交換增大、CPU等待並運行隊列

　　穩定系統的資源狀態

效能項	資源	評價
CPU佔用率	70%	好
	85%	壞
	90%+	很差
磁碟I/0	<30%	好
	<40%	壞
	<50%+	很差
網路	<30%頻寬	好
運行隊列	<2*CPU數量	好
記憶體	沒有頁交換	好
	每個CPU每秒10個頁交換	壞
	更多的頁交換	很差

　　通俗理解：

　　日訪問量

　　常用頁面最大並發數

　　同時線上人數

　　訪問相應時間

　　案例：

　　最近公司一個項目，是個門戶網站，需要做效能測試，根據項目特點定出了主要測試項和測試方案：

　　一種是測試幾個常用頁面能接受的最大並發數(使用者名稱參數化，設定集合點策略)

　　一種是測試伺服器長時間壓力下，使用者能否正常操作(使用者名稱參數化，迭代運行指令碼)

　 　一種則需要測試伺服器能否接受10萬使用者同時線上操作，如果是用IIS做應用伺服器的話，單台可承受的最大並發數不可能達到10萬級，那就必須要使用集 群，通過多台機器做負載平衡來實現；如果是用websphere之類的應用伺服器的話，單台可承受的最大並發數可以達到10萬級，但為效能考慮還是必須要 使用叢集，通過多台機器做負載平衡來實現；通常有1個簡單的計算方式，1個串連產生1個session，每個session在伺服器上有個記憶體空間大小的 設定，在NT上是3M，那麼10萬並發就需要300G記憶體，當然實際使用中考慮其他程式也佔用記憶體，所以準備的記憶體數量要求比這個還要多一些。還有10萬個使用者同時線上，跟10萬個並發數是完全不同的2個概念。這個樓上已經說了。但如何做這個轉換將10萬個同時線上使用者轉換成多少個並發數呢？這就必須要有大量的曆史日誌資訊來支撐了。系統日誌需要有同時線上使用者數量的日誌資訊，還需要有使用者操作次數的日誌資訊，這2個資料的比例就是你同時線上使用者轉換到並發數的比例。另外根據經驗統計，對於1個JAVA開發的WEB系 統（別的我沒統計過，給不出資料），一般1台雙CPU、2G記憶體的伺服器上可支援的最大並發數不超過500個（這個狀態下大部分操作都是逾時報錯而且服務 器很容易宕機，其實沒什麼實際意義），可正常使用（單步非大資料量操作等待時間不超過20秒）的最大並發數不超過300個。假設你的10萬同時線上使用者轉 換的並發數是9000個，那麼你最少需要這樣的機器18台，建議不少於30台。當然，你要是買個大型伺服器，裡面裝有200個CPU、256G的記憶體，千 兆光纖頻寬，就算是10萬個並發使用者，那速度，也絕對是嗖嗖的。

　　另外暴寒1下，光設定全部進入運行狀態就需要接近6個小時。具體的可以拿1個系統來壓一下看看，可能會出現以下情況：

　　1、伺服器宕機；

　　2、用戶端宕機；

　　3、從某個時間開始伺服器拒絕請求，用戶端上顯示的全是錯誤；

　　4、勉強測試完成，但網路堵塞或測試結果顯示時間非常長。假設用戶端和伺服器之間百兆頻寬，百兆/10000=10K，那每個使用者只能得到10K，這個速度接近1個64K的MODEM上網的速度；另外以上分析全都沒考慮系統的後台，比如資料庫、中介軟體等。

　　1、伺服器方面：上面說的那樣的PC SERVER需要50台；

　　2、網路方面：按每個使用者50K，那至少5根百兆頻寬獨享，估計僅僅網路延遲就大概是秒一級的；

　　3、如果有資料庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是肯定頂不住的。資料庫伺服器至少需要10台4CPU、16G記憶體的機器；

　　4、如果有CORBA，那至少再準備10台4CPU、16G記憶體的機器；再加上負載平衡、防火牆、路由器和各種軟體等，總之沒個1000萬的資金投入，肯定搞不定。

　 　這樣的門戶系統，由於有使用者權限，所以並不象jackie所說大多是靜態頁面。但只要是多伺服器的叢集，那麼我們就可以通過1台機器的測試結果來計算多 台機器叢集後的負載能力的，最多額外考慮一下負載平衡和路由上的壓力，比如頻寬、速度、延遲等。但如果都是在1台機器上變化，那我們只能做一些指標上的計 算，可以從這些指標上簡單判斷一下是否不可行，比如10萬並發使用者卻只有1根百兆頻寬，那我們可以計算出每個使用者只有1K頻寬，這顯然是不可行的。但實際 的結果還是需要測試了才知道，畢竟系統壓力和使用者數量不是線性變化的。

　 　這一類系統的普遍的成熟的使用，以及很多軟體在方案設計後就能夠大致估算出系統的效能特點，都導致了系統在軟體效能方面調優的比例並不大（當然不完全排 除後期針對某些代碼和配置進行最佳化後效能的進一步提高），更多的都是從硬體方面來考慮，比如增加記憶體、硬碟做RAID、增加頻寬、甚至增加機器等。

　　網路技術中的10M 頻寬指的是以位計算， 就是 10M bit /秒 ，而下載時的速度看到的是以位元組（Byte）計算的，所以10M頻寬換算成位元組理論上最快下載速度為： 1.25 M Byte/秒!