用戶滿意度
參考Apdex( Application Performance Index)。
Apdex 標准從用戶的角度出發，將對應用響應時間的表現，轉為用戶對於應用性能的可量化為范圍為 0-1 的滿意度評價。
Apdex 定義了應用響應時間的最優門檻為 T，另外根據應用響應時間結合 T 定義了三種不同的性能表現：
- Satisfied（滿意）：應用響應時間低於或等於 T，比如 T 為 1.5s，則一個耗時 1s 的響應結果則可以認為是 satisfied 的。
- Tolerating（可容忍）：應用響應時間大於 T，但同時小於或等於 4T。假設應用設定的 T 值為 1s，則 4 * 1 = 4 秒極為應用響應時間的容忍上限。
- Frustrated（煩躁期）：應用響應時間大於 4T。
計算公式：

Satisfied Count 就是指定采樣時間內響應時間滿足 Satisfied 要求的應用響應次數；而 Tolerating Count 就是指定采樣時間內響應時間滿足 Tolerating 要求的應用響應次數；最后的 Total Samples 就是總的采樣次數總數。從公式可以看出，應用的 Apdex 得分與采樣持續時間無關，與目標響應時間 T 相關（在采用總數固定的情況下，T 通過影響 Satisfied Count以及 Tolerating Count的值間接影響最終的得分）
計算示例：假設應用期待的響應時間能夠在 1000 ms 內，在 100 次采樣中，有 50 次應用響應時間低於 1000 ms，30 次應用響應時間處於 1000 ms 到 4000 ms（ 4 * 1000ms） 之間，剩下 20 次響應時間長於 4000 ms，那么，該應用在 T = 1000ms 的情況下的 Apdex 值為：(50+30/2)/100=0.65
建議：核心功能Apdex不低於0.9，邊緣功能Apdex不低於0.8
響應時間
參考業內2-5-10原則
- 當用戶能夠在2秒以內得到響應時，會感覺系統的響應很快；
- 當用戶在2-5秒之間得到響應時，會感覺系統的響應速度還可以；
- 當用戶在5-10秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；
- 而當用戶在超過10秒后仍然無法得到響應時，會感覺系統糟透了，或者認為系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。 建議：核心功能響應時間2S以內，邊緣功能響應時間5S以內
錯誤率
錯誤率指系統在負載情況下，失敗請求的概率。錯誤率＝(失敗請求數/請求總數)*100%。
建議：核心功能錯誤率不超過千分之六，即小於0.6%，邊緣功能錯誤率不超過千分之十，即小於1%
系統處理能力
系統處理能力是指系統在利用系統硬件平台和軟件平台進行信息處理的能力。
單位：TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒
計算方法：Throughput = (number of requests) / (total time)
吞吐量-負載對應關系：
①上升階段：吞吐量隨着負載的增加而增加，吞吐量和負載成正比；
②平穩階段：吞吐量隨着負載的增加而保持穩定，無太大變化或波動；
③下降階段：吞吐量隨着負載的增加而下降，吞吐量和負載成反比；

a1面積越大，說明系統的性能能力越強，a2面積越大，說明系統穩定性越好，a3面積越大，說明系統的容錯能力越好
軟件指標
| 一級指標 | 二級指標 | 單位 | 解釋 |
|---|---|---|---|
| GC | GC頻率 | 次/秒 | java虛擬機垃圾部分回收頻率 |
| GC時長 | 秒 | 用於垃圾回收的時長 | |
| Thread | 錯誤請求 | 次/秒 | 錯誤請求數 |
| request請求 | 次/秒 | 總request請求數 | |
| 繁忙線程 | 個 | 繁忙線程數 | |
| JDBC | 個 | JDBC連接數 | |
| 調用復雜度 | 層 | 調用復雜度 |
建議：ＧＣ頻率不能頻繁，特別是FULL GC更不能頻繁；當前正在運行的線程數不能超過設定的最大值；當前運行的JDBC連接數不能超過設定的最大值；調用復雜度10以下。
數據庫指標
| 一級指標 | 二級指標 | 單位 | 解釋 |
|---|---|---|---|
| SQL | 耗時 | 微秒 | 執行SQL耗時 |
| 命中率 | Key Buffer命中率 | % | 索引緩沖區命中率 |
| Query Cache命中率 | % | 查詢緩存命中率 | |
| Table Cache命中率 | % | 表緩存命中率 |
mysql Query Cache機制：QueryCache是根據SQL語句來cache的。一個SQL查詢如果以select開頭，那么MySQL服務器將嘗試對其使用QC，若命中該緩存，會立刻返回結果，跳過了解析，優化和執行階段。每個Cache都是以SQL文本作為key來存的。一個被頻繁更新的表如果被應用了QC，可能會加重數據庫的負擔，涉及頻繁更新的表的SQL語句加上SQL_NO_CACHE關鍵詞來對其禁用CACHE，這樣可以盡可能避免不必要的內存操作。
擴展性指標
指應用軟件以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。正常情況下擴展指標應該是線性或者接近線性。
可靠性指標
節點切換、故障恢復耗時1S內，並且無業務中斷（失敗請求）
硬件資源指標
| 序號 | 指標 | 解釋 | 標准 |
|---|---|---|---|
| 1 | CPU使用率 | 指用戶進程與系統進程消耗的CPU時間百分比 | 長時間情況下，一般可接受上限不超過85% |
| 2 | 內存利用率 | 內存利用率=（1-空閑內存/總內存大小）*100% | 一般至少有10%可用內存，內存使用率可接受上限為85%； |
| 3 | 磁盤I/O | 磁盤主要用於存取數據，對應的是寫IO操作與讀IO操作 | 一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能 |
| 4 | 網絡帶寬 | 使用計數器Bytes Total/sec來度量，其表示為發送和接收字節的速率； | 判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較 |
系統按照最大容量的80%或標准壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的時間長短。
穩定性指標
TPS曲線穩定，沒有大幅度的波動;其余各項指標正常。
備注
Minor GC ，Full GC 觸發條件
Minor GC觸發條件：當Eden區滿時，觸發Minor GC。
Full GC觸發條件：
（1）調用System.gc時，系統建議執行Full GC，但是不必然執行
（2）老年代空間不足
（3）方法區空間不足
（4）通過Minor GC后進入老年代的平均大小大於老年代的可用內存
（5）由Eden區、From Space區向To Space區復制時，對象大小大於To Space可用內存，則把該對象轉存到老年代，且老年代的可用內存小於該對象大小