原文鏈接http://blog.csdn.net/strawbingo/article/details/46458959
指標的基本概念
1、事務（Transaction）
在web性能測試中，一個事務表示一個“從用戶發送請求->web server接受到請求，進行處理-> web server向DB獲取數據->生成用戶的object(頁面)，返回給用戶”的過程，一般的響應時間都是針對事務而言的。
2、請求響應時間
請求響應時間指的是從客戶端發起的一個請求開始，到客戶端接收到從服務器端返回的響應結束，這個過程所耗費的時間，在某些工具中，響應通常會稱為“TTLB”，即"Time To Last Byte"，意思是從發起一個請求開始，到客戶端接收到最后一個字節的響應所耗費的時間，響應時間的單位一般為“秒”或者“毫秒”。一個公式可以表示：響應時間＝網絡響應時間+應用程序響應時間。
（1）在1秒鍾之內，頁面給予用戶響應並有所顯示，可認為是“很不錯的”；
（2）在1~2秒鍾內，頁面給予用戶響應並有所顯示，可認為是“好的”；
（3）在2~3秒鍾內，頁面給予用戶響應並有所顯示，可認為是“勉強接受的”；
（4）超過3秒就讓人有點不耐煩了，用戶很可能不會繼續等待下去；
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性能測試中,更根據需要采集相應的參數進行分析。
| 指標 |
說明 |
| 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個頁交換 |
壞 |
|
| 更多的頁交換 |
很差 |
接口性能要求
http接口性能要求
該要求不包括文件上傳 等重量級接口
|
指標名稱
|
要求
|
優先級
|
備注
|
|---|---|---|---|
| 響應時間 | 500 millisecond | 1 | |
| 請求成功率 | 99% | 2 | |
| TPS | 在滿足預期要求的情況下服務器狀態穩定，單台服務器TPS要求在1000左右 |
3 | |
| 資源使用率 | 要求在TPS正常幅度的情況下資源使用率幅度平穩，服務器狀態平穩 | 3 | 要求接口的內部實現不能占用太多資源 |
| 數據庫死鎖 | 0，要求接口在使用過程中不會造成數據庫死鎖 | 1 | |
| CPU限制 | 要求接口在使用過程中不會出現大量的計算 | 3 | |
| 內存 | 要求接口在使用過程中不會出現內存大量消耗的情況 | 3 | |
dubbo接口性能要求
|
指標名稱
|
要求
|
優先級
|
備注
|
|---|---|---|---|
| 響應時間 | 500 millisecond | 1 | |
| 請求成功率 | 99% | 2 | |
| TPS | 在滿足預期要求的情況下服務器狀態穩定，單台服務器TPS要求在1000左右 |
3 | |
| 資源使用率 | 要求在TPS正常幅度的情況下資源使用率幅度平穩，服務器狀態平穩 | 3 | 要求接口的內部實現不能占用太多資源 |
| 數據庫死鎖 | 0，要求接口在使用過程中不會造成數據庫死鎖 | 1 | |
| CPU限制 | 要求接口在使用過程中不會出現大量的計算 | 3 | |
| 內存 | 要求接口在使用過程中不會出現內存大量消耗的情況 | 3 | |
| |