《軟體效能測試、分析與調優實踐之路》(第2版)--第7章節選--常見效能問題分析總結

张永清發表於2024-05-02

1. 效能指標曲線頻繁出現大幅度抖動

如圖7-5-1所示，TPS和平均響應時間出現頻繁的上下抖動。頻繁抖動說明系統並不是一直在穩定地執行，中間會有短暫的停頓，就是持續執行了一段時間後，馬上會停頓一下，然後又繼續執行，持續地這樣交替進行，造成了系統的頻繁劇烈抖動。

圖7-5-1

造成頻繁抖動現象的原因可能有以下幾種：（節選自《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）

（1）系統可能在頻繁的出現Full GC。Full GC是Java 應用程式垃圾回收的一種機制，一般如果出現了Full GC，應用程式就會出現短暫的停頓。關於Full GC的介紹，可以參考本書5.1.7小節中的介紹。此時可以先去看一下應用程式的GC日誌，如果是Full GC 非常頻繁，並且又沒有出現記憶體洩漏，那麼可以參考本書5.4.1 小節中介紹的如何減少GC 來解決這個問題。

（2）系統某一次查詢、修改或者刪除資料耗時很長，導致了整體效能的不穩定。比如，在效能壓測查詢時，大部分引數化傳入的引數，查詢出來的結果資料都很少，但是可能某幾個引數查詢出來的資料量非常大，導致系統在處理這些資料量大的資料時耗時較長。

（3）系統在查詢時，可能有時候能命中快取，有時候命不中快取。命中快取時，查詢會很快；不能命中快取時，需要去查詢資料庫，但是查詢資料庫的時間肯定比快取長，所以就會造成系統效能的不穩定。通常情況下資料庫也會有快取，如果命中了資料庫的快取，查詢也會更快；如果沒有命中，那查詢的耗時肯定也會變久。

（4）如果系統是分散式部署，那麼可以檢查一下分散式處理系統中每個節點的處理能力是否一致，如果不一致，可能也會導致系統頻繁抖動。

（5）伺服器連線不夠用導致的連線批次釋放然後再突然批次連線，一旦批次釋放連線後，系統TPS馬上就會上漲，因為此時可以建立連線了。當連線滿了後，請求就無法處理了，從而不得不等待，進而造成TPS突然下降。

2．在提高併發使用者數時，系統的TPS和平均響應時間一直無法提升

如圖7-5-2所示，當遇到這種情況時，說明系統已經出現了瓶頸，此時可以先去檢查伺服器的CPU、記憶體資源的消耗情況。

圖7-5-2

通常，檢查後會發現應用伺服器的CPU、記憶體等資源都沒有達到使用的上限，但是系統卻出現了處理的瓶頸，那麼說明系統一定是有地方“堵住了”。此時需要繼續做如下檢查：

（1）效能壓測時，點選率是否真的上來了。如果點選率或者單位時間內的請求數沒有上來，那說明是壓測機器無法提供更大壓測能力。尤其在大型的分散式系統中，單臺壓測機往往是不夠用的，因為單臺壓測機不論是網路連線，還是頻寬以及自身CPU、記憶體等都會存在很大限制，效能壓測不止是伺服器資源會有很大消耗，提供壓測能力的壓測機也會很大的資源消耗。

（2）檢查網路頻寬的使用情況，排查瓶頸是否因為網路頻寬限制而導致。此時，需要檢查網路頻寬的環節包括壓測機到Web伺服器、Web伺服器到應用伺服器、應用伺服器到資料庫伺服器等所有存在網路請求互動的地方。如圖7-5-3所示。（節選自《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）

圖7-5-3

（3）參考本書5.3.2小節中使用jstack命令列工具，檢視Java系統的執行緒堆疊，從執行緒堆疊中直接分析當前系統的瓶頸是因為在等待什麼資源，而且該資源可能是一個隱形的不容易發現的資源。

（4）如果對於第（3）點運用不熟的話，可以用最笨的方式就是根據請求處理的鏈路過程，從上而下或者從下而上按順序去排查。此時需要堅信一點，系統肯定是“堵在什麼地方了”，仔細透過checklist去檢查，一定能夠找到這個“堵住”的位置。這就如同自來水的供水系統一樣，如果某個使用者突然反饋說，我家自來水水壓很小，水壓一直都上不去，那麼自來水公司的維修人員上門之後，肯定是從這個使用者家作為起點，然後對供水鏈路中的每個環節進行排查，直到找到是哪個環節出現了擁堵。（節選自《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）

（5）如果按照前面四點還是找不到問題原因的話，那麼可以嘗試減少中間環節從而減少不確定因子的影響，再進行壓測對比，先確定問題可能的範圍，然後再在某個明確的範圍內查詢具體的原因。比如如圖所示，將Web伺服器去掉，讓壓測機的請求直接對應用伺服器進行壓測。如圖7-5-4所示。