一、性能測試分類
1、 負載測試load testing：測試系統能達到的峯值指標；
2、 壓力測試stress testing：強調在極端條件下系統的穩定性，確定什麼條件下系統性能處於失效狀態；
3、 容量測試volume testing：數據庫最佳容量、最大容量，服務器連接能力等；
4、 配置測試configuration testing：獲得不同配置下的性能指標；
5、 基準測試benchmark testing：基於配置測試的調優測試；
6、 併發測試concurrency testing
備註：負載測試、壓力測試的區別，舉例“
百度查詢的響應時間不超過5秒。
負載測試：確認當查詢的響應時間不超過5秒時，系統支持的最大併發用戶數；
壓力測試：確認當系統的最大併發用戶數超過多少時，查詢的響應時間不可接受（如1分鐘）
二、性能測試指標
1、 響應時間：通過事務函數來統計響應時間
2、 吞吐量TPS transaction per second：每秒處理事務/請求/單位數據的數量
3、服務器資源佔用：cpu佔用率、內存使用率、查詢Cache命中率
4、點擊數：向webservice發起的http請求書（鼠標點擊一次可發多個請求）
三、怎樣定性能指標
http://my.oschina.net/dlpinghailinfeng/blog/186161
1、80～20原理：每個工作日中80％業務在20％的時間內完成
2、 估算併發數的公示：
(1) 計算平均的併發用戶數： C = nL/T
(2) 併發用戶數峯值： C’ ≈ C+3根號C
公式(1)中，C是平均的併發用戶數;n是login session的數量;L是login session的平均長度;T指考察的時間段長度泊松分佈估算系統的性能目標
一般的做法是把每天訪問系統用戶數的10%作爲平均的併發用戶數。最大的併發用戶數乘上一個值，2或者3
3、響應時間：
在互聯網上對於用戶響應時間，有一個普遍的標準。2/5/10秒原則。 也就是說，在2秒之內給客戶響應被用戶認爲是“非常有吸引力”的用戶體驗。在5秒之內響應客戶被認爲“比較不錯”的用戶體驗，在10秒內給用戶響應被認爲“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那麼大多用戶會認爲這次請求是失敗的
另：標準可參考國外的3/5/10原則：
（1）在3秒鐘之內，頁面給予用戶響應並有所顯示，可認爲是“很不錯的”；
（2）在3~5秒鐘內，頁面給予用戶響應並有所顯示，可認爲是“好的”；
（3）在5~10秒鐘內，頁面給予用戶響應並有所顯示，可認爲是“勉強接受的”；
（4）超過10秒就讓人有點不耐煩了，用戶很可能不會繼續等待下去；
|
指標 |
說明 |
| 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個頁交換 | 壞 | |
| 更多的頁交換 |
很差 |
四、TPS、響應時間、吞吐量的理解
TPS是衡量服務處理能力的指標；
事務的概念是一個過程中各個環節組成的過程的整體；
用事務的概念來看TPS中的T，一次網絡訪問中從服務接收到請求（起），到服務完成響應（止）的整個過程就是一個事務；
在這個過程中，可能會包含很多環節，例如服務還需要從另外的數據庫服務中獲取數據，從其他中間件、網絡中獲取資源，服務內部的程序邏輯需要做數據處理、計算等等，但無論怎樣，這些過程都會包含在請求和響應之間；
服務完成客戶端的這樣的一個過程就是完成一次事務，單位時間內（通常用秒）服務能完成多少個這樣的事務就是TPS，就是衡量服務處理能力的指標。
響應時間可以理解爲是用於衡量單次事務所花費的時間，但是也不絕對如此，不同的場景下也會用於衡量單次請求的時間……不論如何都是衡量都是統計單次的。既然是單次的這就有個問題，對於同一個過程，單次的時間也可能不同，所以響應時間又會衍生出最大響應時間，最小響應時間，平均響應時間，90%響應時間等等；
很多時候，吞吐量和TPS可以看做是等價的，都是單位時間裏完成任務的數量。但在特定的場景的概念定義又會有些小差別。不同的工具的叫法也不同，Jmeter裏就是吞吐量Throughput，貌似沒有TPS。
很多概念背後的本質是相同的，只是定義得角度不同，關注得細節不同。山就是那座山，遠看成嶺側成峯，人站的位置不同看到的景色也不同。