@效能瓶頸案例及定位方法，純手打，轉載請註明出處

效能測試過程中遇到瓶頸，怎麼辦

總結下這些年遇到最常見的效能瓶頸，響應時間不達標
一般測試：這裡顯示資料怎麼這麼慢？
開發：…

記住，測試不單單要發現問題，還要定位問題出現的原因,找出bug只是測試的責任，定位到問題才是測試能力的體現

話不多說，上乾貨

資料在哪

最簡單的模型：

請求：使用者端→應用伺服器→資料庫
響應：資料庫→應用伺服器→使用者端

1. 正常使用中使用者端傳送請求是使用者的網路，這個沒什麼必要去考慮，因為我們效能測試的目的檢查的是伺服器的效能，使用者愛用啥就用啥，最多就是看下請求資料大小問題，傳送的資料多了，要麼壓縮，要麼就得分拆，別往一個請求裡塞；
2. 資料庫返回資料檢查有沒有慢查詢
3. 應用伺服器接收請求，存取資料庫後處理資料，通俗來講就是後端寫的邏輯程式碼，新手總寫一堆if做判斷，老手已然呼叫方法風生水起

網路分析定位

出現響應時間過長，第一步排查網路
1、調出伺服器的access.log
2、通過裡面的request_time與upstream_response_time進行對比
3、如果request_time遠大於upstream_response_time 則說明請求網路頻寬不足，這時候需要增加頻寬或者壓縮傳輸資料或者分拆請求資料

解釋一下
request_time：
作用是收到請求開始到傳送完響應資料這個時間
upstream_response_time：
從與伺服器建立連線到接收完資料並關閉連線的時間

cpu佔用率高居不下

那如果沒有問題怎麼搞？

那就要看下伺服器的cpu了

top之後 按Shift+P鍵就能按cpu佔用情況排序啦

如果發現有程序佔用巨高，那麼，恭喜你，你找到原因了
我之前遇到有個服務的程序居然cpu佔用率高達70%,然後另一個服務正是對應響應時間變慢的功能介面，妥妥的架構不合理啊，最後解決辦法是搭建了分散式伺服器（當然這是開發乾的活，我只是好奇諮詢了一下），走到現在來看，可能微服務架構會更好一點

快取過多也會導致伺服器響應變慢

1）按正常走下去，cpu如果麼得問題，那記憶體也得瞅瞅
檢視記憶體用到命令 free -m

total是總記憶體
used是已用記憶體
free是可用記憶體

2）再用top檢視下記憶體，大概計算一下是不是等於剛查到的used的值

3）為什麼這樣做，因為我遇到過這種情況，已用記憶體是12GB，但是top查出來的記憶體總和大概9GB，那剩下的3GB呢，跑哪去了？

4）用cat /proc/meminfo檢視記憶體更加詳細的資訊
我發現不見了的3GB近乎全部在Slab（Slab是用於存放核心資料結構快取）下面；

5）通過slabtop命令檢視這部分記憶體的使 用情況，發現大部分記憶體被dentry_cache佔用了；

把問題反饋給開發後，開發通過釋放Slab佔用的cache記憶體空間解決
解決命令需要sudu的許可權
sync
sudo sysctl -w vm.drop_caches=3
sudo sysctl -w vm.drop_caches=0 #recovery drop_caches

資料庫慢查詢

遇到過一個問題，表中沒有建立索引導致響應時間長，CPU佔用變高

有個介面120的tps，cpu使用率卻高達90%，響應時間大於1秒。

定位問題
進入mysql的命令模式
set global slow_query_log = on; 開啟慢查詢紀錄檔
set long_query_time = 1; 設定慢查詢時長為1s
set globle log_output = 路徑/檔名 設定慢查詢紀錄檔檔案存放路徑

意味著查詢超過1s的sql語句寫入慢查詢紀錄檔

通過進入資料庫定位發現該語句沒有建立索引
解決後tps上升到240，響應時間下降到280ms左右。

問：怎麼看有沒有建立索引？
答：mysql命令模式輸入SHOW INDEX FROM 表名

碼字累了，還有一些坑，慢慢更吧~