線上模塊XX 在高QPS下耗時劇增的緣由排查總結

一、肯定問題緣由：
1）場景復現：方式1：根據現場日誌肯定問題緣由；方式2：壓測復現。
存在的問題：方式1：日誌中沒有保存現場；方式2：壓測可能與線上不符；壓測可能沒法知足某些特殊條件。
2）一些手段：
a.若是問題只在特定機器出現，肯定機器硬件配置是否相同，cpu、meminfo、系統配置等；
b.分階段、逐步細化各步驟的處理時間、隊列積壓長度等；
c.可使用一些輔助性能分析工具進行分析，代價是學習成本，場景不必定符合性能分析工具做用的發揮。
最終發現的高qps時，耗時主要集中在信息流配圖階段和it_proc特徵收集階段。

二、分析現象本質：
1）it_proc:
內部循環過多：按照it內部的參數默認值計算，最大循環次數達到百萬級別，在其餘特徵收集基本0ms的狀況下，it的耗時是不可接受的。
2）信息流配圖：
分階段、逐步細化各步驟的處理時間並不能發現問題緣由，這種狀況就不能懷疑單次執行內部函數的耗時上，頗有多是系統在作切換、同步等處理時致使的異常。
對這一部分程序從新研讀，發現調用的std標準函數random_shuffle有重大嫌疑，在此懷疑的基礎上，註釋掉相關代碼，確實再也不發生一樣的問題，問題獲得確認。

問題參考資料：
http://www.cplusplus.com/refe...
is-random-shuffle-threadsafe-and-using-rand-r-if-it-is-not
https://github.com/mariusmuja...

三、問題修復方式：
1）it_proc:
和策略同窗討論修復方式，誰開發誰維護的原則，發現是按權重抽樣算法過於複雜，最後肯定已現有ot的處理方式進行修改；
2）信息流配圖：
a. 信息流配圖也存在大量循環，首先將不須要再循環內部執行的代碼移到循環體外部，其次儘可能在不影響功能的狀況降低低循環次數。
b.對於random_shuffle的問題，採用基於rand_r自定義隨機生成器的方式調用
template void random_shuffle (RandomAccessIterator first, RandomAccessIterator last,RandomNumberGenerator&& gen);
實現數組打散。

四、總結：
1）性能問題排查的思路和步驟（定位問題比解決問題更加困難，沒法定位問題就更談不上解決問題）
2）代碼優化的原則：
a.阿姆達爾定律：不常常使用的代碼不須要作較多優化考慮，即讓常常執行的路徑運行更加高效，而運行稀少的路徑正確執行。
b.先保證代碼的正確性，再考慮優化。
c.優化所需的時間經常是寫代碼時間的double。
3）優化分爲系統級別的優化和代碼級別的優化
系統級別的優化經常須要模塊或子模塊的重構，須要從頂端開始出方案和設計。推薦書目：《重構-改善既有代碼的設計》
代碼級別的優化更多的是使用一下小技巧實現，若是能夠參考這幾個連接：

http://www.jb51.net/article/5...
http://blog.csdn.net/wind19/a...