關於性能優化

    記錄一下最近的一次性能優化的簡單過程。    

    最近公司跟別的公司有一個業務合做，須要提供一個接口給對方調用。 接口屬於計算型接口，對方輸入數據進來，在咱們應用內部進行邏輯計算，而後輸出數據。

    因爲，對方公司流量比較大，對接口性能有必定的要求。目標是4核4G內存單機QPS要在 1000以上。

   初始的時候，先在閒置的測試服務器上(單核1G內存1Mbps帶寬)作了一輪壓測，結果QPS只能達到180左右就上不去了。這時候考慮優化的事情。

    1、首先想到的是精簡接口計算過程當中的依賴，把一些沒必要要的依賴排除。在梳理依賴的過程當中，發如今計算中有幾回依賴DB查詢的動做。

    先就重點優化這塊，把依賴DB的數據在應用啓動時候就熱加載在內存中(大概幾百M的樣子)，這樣在接口計算時候所有都是內存操做。

   這個時候仍是在上面的測試機器上又作了一輪壓測，結果發現提高不明顯，QPS仍是在230左右。

 

    2、這時候請教了有經驗的朋友，朋友提供了三點頗有用的信息。

第一，在單核1G內存機器上230左右的QPS已經算還能夠了，至少不是不好。

第二，在接口內部各個節點增長消耗時間的日誌，好排查究竟是哪裏的時間開銷比較大，定位出問題點。

第三，若是整個計算都在內存中進行，仍是很慢的話，看看是否是有浮點數的運算致使運算量增大。

按照上面的步驟，確實很快就定位到了問題點，在計算內部有一套算法用到了浮點數的運算，致使併發量大的時候，RT瞬間就上去了。

 

    3、把上面消耗時間較多的兩個點，所有重構了一遍，去除了浮點數的運算。(把一些實時計算結果，預先加載到內存中)，用內存來換計算時間。

優化作完後，再上面測試機上壓測，發現QPS仍是230-240左右，這時候多了個心眼，查看了一遍網卡狀況，發現流出數據量已經達到最大。也就是QPS一直被1Mbps的帶寬拖累。

其實咱們一次請求輸入和輸出數據都不大，100byte 的樣子。

按照理論來算，1MBPS=0.125Mb=128Kb， 理論上是能夠支撐1000QPS的。可是實際狀況確只有1/4。

   

    4、找到了問題點，接着換了一臺線上的正式機器 4核8G，

帶寬5Mbps 壓測出來，QPS達到了1200左右，帶寬繼續佔滿。

接着增長帶寬到50Mbps 壓測，QPS達到了2700-5000左右。這個時候纔是優化後的正常值。