《軟體效能測試分析與調優實踐之路》(第2版) 是清華大學出版社出版的一本圖書，作者為張永清，全書共分為9章，如下圖所示
圖書介紹：《軟體效能測試分析與調優實踐之路》(第2版)
本文是接著
《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記（一）總體介紹（上）-真正從效能分析與調優來看效能測試
繼續往下講。
6）、效能分析與調優實踐（索引與分庫分表）
分庫分表時，插入資料時，可以按照如下圖所示的方式來進行分庫分表的寫入資料。
查詢資料時可以按照如下圖所示的方式來進行查詢，下圖中的路由表非常的關鍵，用於能快速的定位到需要查詢的資料是在哪個分庫和分表中。
7）、效能分析與調優實踐（層層過濾）
層層過濾的重點如下：
- 在不同的層級儘可能過濾掉對應層級的所有該過濾的無效請求，讓最末端進入到資料庫中的請求都是有效的請求。
- 錯誤前置，提前丟擲異常。對於異常的請求，越早丟擲異常，越有利於減輕系統的處理能力和節省資源的佔用。
- 避免重複請求以及透過機器人的惡意請求，從而降低系統的處理壓力，更好的保護系統。《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記
7、效能分析與調優實踐（常見效能問題）
1）、效能指標曲線頻繁出現大幅度抖動
- （1）系統可能在頻繁的出現Full GC。Full GC是Java 應用程式垃圾回收的一種機制，一般如果出現了Full GC，應用程式就會出現短暫的停頓。關於Full GC的介紹，可以參考紙質書5.1.7小節中的介紹。此時可以先去看一下應用程式的GC日誌，如果是Full GC 非常頻繁，並且又沒有出現記憶體洩漏，那麼可以參考紙質書5.4.1 小節中介紹的如何減少GC 來解決這個問題。《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記
- （2）系統某一次查詢、修改或者刪除資料耗時很長，導致了整體效能的不穩定。比如，在效能壓測查詢時，大部分引數化傳入的引數，查詢出來的結果資料都很少，但是可能某幾個引數查詢出來的資料量非常大，導致系統在處理這些資料量大的資料時耗時較長。《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記
- （3）系統在查詢時，可能有時候能命中快取，有時候命不中快取。命中快取時，查詢會很快；不能命中快取時，需要去查詢資料庫，但是查詢資料庫的時間肯定比快取長，所以就會造成系統效能的不穩定。通常情況下資料庫也會有快取，如果命中了資料庫的快取，查詢也會更快；如果沒有命中，那查詢的耗時肯定也會變久。《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記
- （4）如果系統是分散式部署，那麼可以檢查一下分散式處理系統中每個節點的處理能力是否一致，如果不一致，可能也會導致系統頻繁抖動。《軟體效能測試分析與調優實踐之路》(第2版) 讀書筆記
- （5）伺服器連線不夠用導致的連線批次釋放然後再突然批次連線，一旦批次釋放連線後，系統TPS馬上就會上漲，因為此時可以建立連線了。當連線滿了後，請求就無法處理了，從而不得不等待，進而造成TPS突然下降。
2）、在提高併發使用者數時，系統的TPS和平均響應時間一直無法提升
通常，檢查後會發現應用伺服器的CPU、記憶體等資源都沒有達到使用的上限，但是系統卻出現了處理的瓶頸，那麼說明系統一定是有地方“堵住了”。此時需要繼續做如下檢查：
- （1）效能壓測時，點選率是否真的上來了。如果點選率或者單位時間內的請求數沒有上來，那說明是壓測機器無法提供更大壓測能力。尤其在大型的分散式系統中，單臺壓測機往往是不夠用的，因為單臺壓測機不論是網路連線，還是頻寬以及自身CPU、記憶體等都會存在很大限制，效能壓測不止是伺服器資源會有很大消耗，提供壓測能力的壓測機也會很大的資源消耗。
- （2）檢查網路頻寬的使用情況，排查瓶頸是否因為網路頻寬限制而導致。此時，需要檢查網路頻寬的環節包括壓測機到Web伺服器、Web伺服器到應用伺服器、應用伺服器到資料庫伺服器等所有存在網路請求互動的地方。如下圖所示。（《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）
- （3）參考紙質書5.3.2小節中使用jstack命令列工具，檢視Java系統的執行緒堆疊，從執行緒堆疊中直接分析當前系統的瓶頸是因為在等待什麼資源，而且該資源可能是一個隱形的不容易發現的資源。
- （4）如果對於第（3）點運用不熟的話，可以用最笨的方式就是根據請求處理的鏈路過程，從上而下或者從下而上按順序去排查。此時需要堅信一點，系統肯定是“堵在什麼地方了”，仔細透過checklist去檢查，一定能夠找到這個“堵住”的位置。這就如同自來水的供水系統一樣，如果某個使用者突然反饋說，我家自來水水壓很小，水壓一直都上不去，那麼自來水公司的維修人員上門之後，肯定是從這個使用者家作為起點，然後對供水鏈路中的每個環節進行排查，直到找到是哪個環節出現了擁堵。 （《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）
- （5）如果按照前面四點還是找不到問題原因的話，那麼可以嘗試減少中間環節從而減少不確定因子的影響，再進行壓測對比，先確定問題可能的範圍，然後再在某個明確的範圍內查詢具體的原因。比如如圖所示，將Web伺服器去掉，讓壓測機的請求直接對應用伺服器進行壓測。如下圖所示。
3）、提高併發使用者數時，系統的TPS緩慢下降且平均響應時間緩慢上升
當系統出現TPS下降而平均響應時間緩慢上升，可能是系統已經出現了效能的拐點，達到了最大的處理能力了。此時需要做一下如下檢查
- （1）應用伺服器資源，比如CPU、記憶體、IO等是否已經達到了使用上限。
- （2）資料庫伺服器的資源以及資料庫的連結數等是否已經達到了使用上限。
- （3）如果第（1）點或者第（2）點中的資源使用已經達到了上限，可以對伺服器資源進行擴容後，再重新繼續壓測。通常情況下，效能出現拐點時，伺服器中某項資源也達到了使用的上限。
4）、效能壓測過程中，伺服器記憶體資源使用率一直在逐步緩慢上升，隨著效能壓測的持續進行，從來不會出現下降或者在一定範圍內小幅度波動，並且此時TPS也在緩慢下降
當出現這種情況時，很有可能是出現了記憶體洩露，此時可以做如下檢查：
- （1）檢視系統日誌，看看有沒有記憶體溢位的報錯資訊。
- （2）在效能壓測過程中參考使用紙質書5.2.1小節中的jconsole或者5.2.2小節中的jvisualvm來進一步定位Java JVM 是否存在記憶體洩露。（《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）
- （3）如果存在JVM 記憶體洩露，可以參考使用紙質書5.3.3小節中的MemoryAnalyzer工具來進一步分析是程式碼中哪個地方出現了記憶體洩露。
- （4）效能壓測過程中，當併發使用者數和點選率不變的情況下，伺服器的資源消耗應該是在一個穩定的範圍內，或者在一定範圍內不斷地小幅度波動，這才是比較正常的。
- （4）如果第（3）點無法排查到具體的問題，可以參考紙質書1.6.1小節中的分層分析的方式來定位問題。
5）、在分散式部署環境下的效能壓測過程中出現每臺應用伺服器CPU或者記憶體資源消耗相差太大
當出現這種現象時，可以做如下排查：
- （1）檢查每臺應用伺服器的硬體配置是否一致。（《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）
- （2）檢查每臺應用伺服器的作業系統，應用軟體、資料庫軟體、JDK軟體等版本以及配置資訊是否一致。（《軟體效能測試、分析與調優實踐之路》(第2版)，作者張永清，轉載請註明出處）
- （3）如果第（1）點和第（2）點都沒問題，檢查Web伺服器轉發請求到應用伺服器的負載均衡是否均勻。比如Nginx配置中是否有轉發的權重不一致，或者有ip_hash等的配置限制，具體可以參考紙質書3.1.1小節中的介紹。