路由管理性能優化之路

去年的時候，測試1W條路由的收斂性能，大概需要5s以上，這個成績比較差，當時分析了一下，認為是路由管理模塊不支持路由更新的操作導致的，這樣會浪費1倍的消息處理。今年這個問題又重新提起，由於這次有著比較明確的優化目標，因此不再像去年那樣純粹的看代碼猜測。

首先，使用perf + 火焰圖查看了本進程的熱點函數，關掉了一些浪費性能的日誌，優化了一些熱點，並提供了路由更新的 發功能，現性能從5s到了1.6s。看起來數據很漂亮，但是仔細分析，更新提供的性能提升也就不到1s，熱點優化也提供的不多，最大的提升居然是一個2s的定時器！把定時器改為了20ms，節約了大約2s的時間。而這個2s的定時器實際上是不需要這麼久的。當時設為2s只是當年的維護人員不熟悉業務邏輯導致的。

由於還沒有達到目標，繼續優化，此時通過火焰圖已經看不出什麼東西了。這個時候通過打點，記錄關鍵時間，根據火焰圖中的熱點函數打了一些點，發現路由管理模塊佔用了1.3s的時間。進一步分析，發現是上游業務在發送路由時，最後一個消息總是比前面的消息慢了900ms左右時間，經過代碼分析，發現又是一個1s的定時器導致的。為了提升消息性能，聚合多個路由消息一起發送，但當消息緩存不滿時，設置了1s的定時器。這個定時器直接導致路由管理浪費了1s的時間。修改後，發現路由管理1w條路由只需要 400ms左右的時間，這部分已經接近硬體設備的性能了。

但……總時間仍然是1.6s！繼續分析，發現通往轉發的表項整合模塊有性能瓶頸。前面的1s定時器掩蓋了他的瓶頸，取消後暴露了出來。由於這部分是GO編寫的，也只能靠打點。這個時候，涉及到GO內部處理的一些東西就不好掌控了（比如內存申請、釋放），此時只能感嘆還是需要C。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！