在併發量一定的情況下如何對系統響應時間進行詳細分析
分析步驟
1.1 在關鍵點位新增日誌資訊 -> 縮小目標範圍
a) 主要函式耗時
b) 訪問外部系統耗時：DB、MQ、Cache、FileSystem、RPC、HTTP等
c) 介面內不同邏輯耗時百分比/絕對值
1.2 詳細分析瓶頸出現原因
a) 技術層面：優先考慮
b) 業務邏輯：業務邏輯改造一般影響較大、耗時較長，優先順序低
1.3 針對性解決問題
一旦定位了問題原因，解決問題的方法都相當容易
技術層面
2.1 程式碼實現
a) 序列邏輯是否可以並行化
b) 序列請求是否可以批量(batch)請求
c) SQL是否需要優化
d) 演算法複雜度是否需要優化
e) 語言核心庫是否提供了效能更高的使用方式
f) 引用的第三方庫是否存在效能問題
g) 每次外部請求是否都重新建立連線
2.2 核心/硬體層面
a) CPU使用率
b) 記憶體使用率
c) 磁碟IO狀況
d) 網路狀況
d) 瓶頸是否由呼叫的核心函式引起？
該函式是如何工作的；新版本核心是否已經對此優化；如何調整使用方式可以更高效
2.3 日誌
執行緒會爭奪日誌鎖，在高併發情況下，同步寫日誌很影響效能。非同步寫又可能引起OOM。
業務邏輯
隨著業務的增長，介面負擔的功能原來越複雜，邏輯鏈路越來越長，事務越來越大，效能越來越差，越來越沒辦法維護。（如果有人負責把控、從相對長遠些的角度設計系統的迭代，這種情況本是可以避免的）
優化辦法只有一個就是：保留主鏈路，旁支鏈路非同步化。
常用工具
4.1 核心
a) CPU: top、vmstat htop w uptime dstat
b) MEM: top、free
c) disk IO: iostat
例: iostat -kx 1 //每秒統計一次io
iotop -o //檢視磁碟使用率較高的程式
d) 網路
流量：sar -n DEV 1 3 //每秒統計一次所有網路卡流量，共3次
網路抓包: tmpdump，可配合tmptrace、wireshark分析
TCP連線狀況：netstat -an | grep TIME_WAIT //client端近期關閉tcp連線數量
e) 檢視/proc/xxx中的系統詳細資訊
小知識
a) 網路抖動引起tcp重傳，一般內部系統之間的呼叫，linux設定的重傳時間間隔為至少200ms以上。
b) 服務之間通過網路呼叫，網路開銷在500us ~ 2ms
c) 機械磁碟定址: 20ms
d) 磁碟的某page中如果存在資料，程式寫此page時如果不會填充整個page，核心會先載入整個page，再輸出整個page，保證磁碟資料不丟。這會導致一次被動讀磁碟，效能損耗會很大。否則會直接寫入磁碟快取記憶體，間隔固定時間刷盤一次(5s)。
e) 日誌使用seaslog buffer
隨著系統併發量的增加，系統響應時間會逐步下降甚至雪崩，一般是由多執行緒之間、模組之間、子系統之間爭奪資源（鎖）引起的。