1. 系統性能指標包括哪些？
業務指標、資源指標、中間件指標、數據庫指標、前端指標、穩定性指標、批量處理指標、可擴展性指標、可靠性指標。
1）業務指標：主要包括並發用戶數、響應時間、處理能力。
|
指標
|
定義
|
簡稱
|
標准
|
|
交易響應時間
|
指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。
|
Response Time: RT
|
對於在線實時交易：
互聯網企業：500毫秒以下，例如淘寶業務10毫秒左右。
金融企業：1秒以下為佳，部分復雜業務3秒以下。
保險企業：3秒以下為佳。
制造業：5秒以下為佳。
對於批量交易：
不同數據量結果是不一樣的，大數據量的情況下，2小時內完成。
|
|
系統處理能力
|
指系統在利用系統硬件平台和軟件平台進行信息處理的能力。
系統處理能力通過系統每秒鍾能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，后者稱為事務。兩種交易指標都可以評價應用系統的處理能力。一般建議與系統交易日志保持一致，以便於統計業務量或者交易量。
|
HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。
對於互聯網業務中，如果某些業務有且僅有一個請求連接，那么TPS=QPS=HPS。
一般情況下，用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器點擊請求。
|
無論TPS、QPS、HPS,此指標是衡量系統處理能力非常重要的指標，越大越好。
|
|
並發用戶數
|
指在同一時刻內，登錄系統並進行業務操作的用戶數量。在測試中，采用虛擬用戶來模擬現實中用戶進行業務操作。
|
Virtual User: VU
|
一般情況下，性能測試是將系統處理能力容量測出來，而不是測試並發用戶數，除了服務器長連接可能影響並發用戶數外，系統處理能力不受並發用戶數影響，可以用最小的用戶數將系統處理能力容量測試出來，也可以用更多的用戶將系統處理能力容量測試出來。
|
|
錯誤率
|
指系統在負載情況下，失敗交易的概率。
錯誤率＝(失敗交易數/交易總數)*100%。
穩定性較好的系統，其錯誤率應該由超時引起，即為超時率。
|
Failure Ratio: FR
|
不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低於99.4%。
|
2）資源指標：CPU資源利用率、內存利用率、磁盤I/O、網絡I/O、內核參數(信號量、打開文件數)等。
|
指標
|
定義
|
簡稱
|
標准
|
|
CPU
|
中央處理器是一塊超大規模的集成電路，是一台計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。
|
Central Processing Unit：CPU
|
CPU指標主要指的CPU利用率，包括用戶態(user)、系統態(sys)、等待態(wait)、空閑態(idle)。
CPU利用率要低於業界警戒值范圍之內，即小於或者等於75%;
CPU sys%小於或者等於30%,
CPU wait%小於或者等於5%。
CPU Load要小於CPU 核數。
|
|
內存
|
內存是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的，因此內存的性能對計算機的影響非常大。
|
Memory就是內存的簡稱
|
現代的操作系統為了最大利用內存，在內存中存放了緩存，因此內存利用率100%並不代表內存有瓶頸，衡量系統內有有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低於70%,太多的交換將會引起系統性能低下。
|
|
磁盤吞吐量
|
指在無磁盤故障的情況下單位時間內通過磁盤的數據量。
|
Disk Throughput
|
磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據，一般情況下，磁盤繁忙率要低於70%。
|
|
網絡吞吐量
|
指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。用於衡量系統對於網絡設備或鏈路傳輸能力的需求。
當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡設備。
|
Network Throughput
|
網絡吞吐量指標主要有每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的70%。
|
內核參數主要包括信號量、進程、文件句柄，一般不要超過設置的參數值即可，具體如下:
|
二級指標
|
解釋
|
單位
|
|
Maxuprc
|
限制每個用戶的用戶進程的最大數量
|
個
|
|
Max_thread_proc
|
定義每個進程允許的最大線程數量
|
個
|
|
Filecache_max
|
最大可用於cache file I/O的物理內存
|
字節
|
|
Ninode
|
內存中 HFS 文件系統打開 i 節點的最大數量
|
個
|
|
Nkthread
|
限制允許同時運行的線程數量
|
個
|
|
Nproc
|
限制允許同時運行的進程數量
|
個
|
|
Nstrpty
|
基於 STREAMS 的偽終端 (pts) 的最大數量
|
個
|
|
Maxdsiz
|
任何用戶進程的數據段的最大大小（以字節為單位）
|
字節
|
|
maxdsiz_64bit
|
任何用戶進程的數據段的最大大小（以字節為單位）
|
字節
|
|
maxfiles_lim
|
每個進程的文件描述符的最大數目硬限制
|
個
|
|
maxssiz_64bit
|
任何用戶進程的堆棧的最大大小
|
字節
|
|
Maxtsiz
|
任一用戶進程的文本段的最大大小
|
字節
|
|
nflocks
|
文件鎖的最大數量
|
個
|
|
maxtsiz_64bit
|
任一用戶進程的文本段的最大大小
|
字節
|
|
msgmni
|
系統級 System V IPC 消息隊列 (ID) 所允許的最大數量
|
個
|
|
msgtql
|
系統中任意時間的最大 System V IPC 消息數
|
個
|
|
npty
|
BSD 偽終端 (pty) 的最大數量
|
個
|
|
nstrtel
|
指定內核可支持傳入 telnet 會話的 telnet 設備文件的數量
|
個
|
|
nswapdev
|
可用於交換的設備的最大數量
|
個
|
|
nswapfs
|
可用於交換的文件系統的最大數量
|
個
|
|
semmni
|
System V IPC 系統級信號量標識符的數量
|
個
|
|
semmns
|
System V 系統級信號量的數量
|
個
|
|
shmmax
|
System V 共享內存段的最大大小
|
字節
|
|
shmmni
|
系統中 System V 共享內存段標識符的數量
|
個
|
|
shmseg
|
每個進程 System V 共享內存段的最大數量
|
個
|
3）中間件指標：常用的中間件例如Tomcat、Weblogic等指標主要包括JVM, ThreadPool, JDBC。
|
指標
|
二級指標
|
解釋
|
單位
|
|
GC
|
GC頻率
|
java虛擬機垃圾部分回收頻率
|
每秒多少次
|
|
Full GC頻率
|
java虛擬機垃圾完全回收頻率
|
每小時多少次
|
|
|
Full GC平均時長
|
用於垃圾完全回收的平均時長
|
秒
|
|
|
Full GC最大時長
|
用於垃圾完全回收的最大時長
|
秒
|
|
|
ThreadPool
|
Active Thread Count
|
活動的線程數
|
個
|
|
Pending User Request
|
處於排隊的用戶請求個數
|
個
|
|
|
JDBC
|
JDBC Active Connection
|
JDBC活動連接數
|
個
|
標准
當前正在運行的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下，線程數最小值設置50和最大值設置200比較合適。
當前運行的JDBC連接數不能超過設定的最大值。一般情況下系統性能較好的情況下，JDBC最小值設置50和最大值設置200比較合適。
GC頻率不能頻繁，特別是FULL GC更不能頻繁，一般情況下系統性能較好的情況下，JVM最小堆大小和最大。
4）數據庫指標：SQL、吞吐量、命中率、鎖。
|
指標
|
二級指標
|
解釋
|
單位
|
|
SQL
|
耗時
|
執行SQL耗時
|
微秒
|
|
吞吐量
|
QPS
|
每秒查詢次數
|
個
|
|
TPS
|
每秒事務次數
|
個
|
|
|
命中率
|
Key Buffer命中率
|
索引緩沖區命中率
|
百分之
|
|
InnoDB Buffer命中率
|
InnoDB緩沖區命中率
|
百分之
|
|
|
Query Cache命中率
|
查詢緩存命中率
|
百分之
|
|
|
Table Cache命中率
|
表緩存命中率
|
百分之
|
|
|
Thread Cache命中率
|
線程緩存命中率
|
百分之
|
標准
SQL耗時越小越好，一般情況下微秒級別。
命中率越高越好，一般情況下不能低於95%。
鎖等待次數越低越好，等待時間越短越好。
5）前端指標：頁面加載時間、頁面數量、網絡時間（DNS，連接時間、傳輸時間等）。
|
指標
|
二級指標
|
解釋
|
單位
|
|
頁面展示
|
首次顯示時間
|
在瀏覽器地址欄輸入URL按回車到用戶看到網頁的第一個視覺標志為止
|
毫秒
|
|
OnLoad事件時間
|
瀏覽器觸發onLoad事件的時間，當原始文檔和所有引用的內容完全下載后才會觸發這個事件
|
毫秒
|
|
|
完全載入的時間
|
所有onLoad JavaScript 處理程序執行完畢，所有動態的或延遲加載的內容都通過這些處理程序觸發的時間
|
毫秒
|
|
|
頁面數量
|
頁面大小
|
整個頁面大小
|
KB
|
|
請求數量
|
從網站下載資源時所有網絡請求的總數，盡量少
|
次
|
|
|
網絡所花時間
|
DNS時間
|
DNS查找時間
|
毫秒
|
|
連接時間
|
瀏覽器與Web服務器建立TCP/IP連接的時間
|
毫秒
|
|
|
服務器時間
|
服務器處理時間
|
毫秒
|
|
|
傳輸時間
|
內容傳輸所用時間
|
毫秒
|
|
|
等待時間
|
等待某個資源釋放的時間
|
毫秒
|
標准
頁面要盡可能小及壓縮。
頁面展示和花費時間越短越好。
6）穩定性指標
最短穩定時間：系統按照最大容量的80%或標准壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。
一般來說，對於正常工作日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。對於7*24運行的系統，至少應該能夠保證系統穩定運行24小時以上。
標准
TPS曲線穩定，沒有大幅度的波動。
各項資源指標沒有泄露或異常情況。
7）批量處理指標：指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。
處理效率是估算批量處理時間窗口最重要的計算指標。
關於批量處理時間窗口，不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外，同一系統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。
標准
在數據量很大的情況下，批處理時間窗口時間越短越好。
不能影響實時交易系統性能。
8）可擴展性指標：指應用軟件或操作系統以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。
計算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。
擴展能力應通過多輪測試獲得擴展指標的變化趨勢。
標准
理想的擴展能力是資源增加幾倍，性能就提升幾倍。
擴展能力至少在70%以上。
9）可靠性指標：雙機熱備、集群、備份和恢復。
|
指標
|
測試內容
|
|
雙機熱備
|
節點切換是否成功及其消耗時間
雙機切換是否有業務中斷
節點回切是否成功及其耗時
雙機回切是否有業務中斷
節點回切過程中的數據丟失量
|
|
集群
|
集群中某個節點出現故障時，系統是否有業務中斷情況出現
在集群中新增一個節點時，是否需要重啟系統
當故障節點恢復后，加入集群，是否需要重啟系統
當故障節點恢復后，加入集群，系統是否有業務中斷情況出現
節點切換需要多長時間
|
|
備份和恢復
|
備份是否成功及其消耗時間
備份是否使用腳本自動化完成
恢復是否成功及其消耗時間
恢復是否使用腳本自動化完成
|
2. 具體性能的分析流程？
首先看關鍵指標是否滿足需求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種可能性非常小）。
如果是服務器端的問題，需要定位的問題有硬件相關指標，例如CPU，Memory，Disk I/O，Network I/O，如果是某個硬件指標有問題，需要深入的進行分析。如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查SQL，命中率，鎖，參數設置。
如果以上指標都正常，應用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。
3. 如果讓你去優化前端頁面，你的優化流程是？
遇到問題，第一步是確定問題，先要確定是前端的問題還是后端的問題。
如果是前端的問題，那就要確定在哪些地方出了問題，按照前端的各種檢測方法來檢查。
如果是后端的問題，就從系統、中間件、數據庫、網絡等方面入手。
如何確定問題呢？
比如用Firefox的firebug調試，看一次請求在各部分分別花了多少時間，哪些請求耗時最長。
如果請求的是靜態資源，時間很長，就需要考慮部署CDN啥的；
如果請求的不是靜態資源而是服務器數據，時間長速度慢，那就分兩種情況進行考慮：第一是后端的問題，第二是前端渲染問題。
如果返回數據很快，但界面數據沒出來，就要考慮是前端js程序問題還是圖片等資源太大的問題等等。