性能優化

性能的目標

跑得更快嗎？是用更少的資源跑得更快。若是不能兼得，咱們一般選擇跑得更快，這也是大多數時候性能優化的目的，也有些時候性能優化是爲了減小資源消耗。

 

系統性能的定義

1.吞吐量，系統每s能處理的請求數、任務數

2.時延，系統處理一個請求或者任務的耗時

3.併發數，次級指標，同時接入的客戶端數量有時也會成爲一個考覈指標，通常的後臺服務會要求支持100-1000區間的併發鏈接數，而網站會要求支持10K甚至更大的併發數。

 

時延和吞吐量每每呈現某種正比關係，吞吐量越高，時延趨於越大，當請求超過系統處理能力時，時延趨於無限大。

而且根據實際經驗，時延不會是一個穩定的值，而是一個波動範圍，計算吞吐量須要計算區間以及百分比

 

 提升吞吐量，時延區間從400us隨之增大

 

更嚴重的是，當吞吐量達到必定程度，延遲將會劇烈抖動，出現超長時延，如上圖的>50ms.

 

系統性能測試

收集吞吐量和時延

延遲：每一個系統都是有硬性要求的，網站多是1S-5S，後臺系統好比消息隊列，多是100us-5ms之間。

測試工具：調整併發數來模擬不一樣的吞吐量和時延

在測量延遲的時候，既然延遲是一個區間，咱們就須要用百分比來衡量，好比60%以上的時延在1-3ms區間，容許小於2%的大於3ms，一旦不知足任何一個百分比區間，都說明系統還須要優化，case是無效的。

性能測試也要經得起時間考驗，一個程序只能高速運行10分鐘，以後就拖垮了cpu和內存，那是沒有意義的。設計良好的程序在運行1天、1周、1月、1季度、1年後仍應保持同樣的效率。

定位性能瓶頸

1.定位操做系統的負載，若是操做系統的網絡、磁盤、cpu、內存出現了巨量佔用或者不穩定，這時候定位咱們的程序是沒有用的。linux下可使用nmon追蹤cpu、網絡、磁盤、內存的佔用率，這個須要先生成文件，是否分析，也能夠經過iostat、vmstat、top、tcpdump等查看實時的佔用率。

cpu利用率，cpu利用率不高，說明程序忙於作其餘的一些事情。

io，io和cpu利用率通常是相反的，若是cpu利用率沒法提升，說明程序每每在忙於作其餘的事情，好比io，磁盤io或者網絡io。

磁盤io影響程序的緣由通常有：io吞吐量過大，多線程/多進程IO，同步/阻塞IO。

解決io對程序的影響能夠添加或者更換更大吞吐量的磁盤和網卡，下降程序產生io數據的速率（好比下降日誌級別，壓縮後再輸出），下降io同步的頻率（減小fflush到磁盤的頻率，改成1s一次），採用bio機制（把fflush和close這些會阻塞程序的調用經過隊列放到一個bio線程來完成），合併io（同一主機的日誌都寫入到共享內存，由一個子系統日誌server負責日誌的落地）

若是cpu、io、內存、網絡都不高，那程序設計存在問題，最典型的是程序存在單點瓶頸，嘗試把單點瓶頸並行化，也有多是通訊隊列和互斥資源採用了粗粒度的鎖，細化粒度減小衝突發生的機率。

2.定位程序的瓶頸

添加日誌來定位瓶頸，找出程序中調用頻繁且耗時久、單點運行且性能低下的

若是程序存在單點瓶頸，簡化單點瓶頸的工做量或者嘗試並行化處理，並行化的過程雖然會帶來互斥的額外開銷，但能夠經過細化粒度下降對性能的影響。

具體的措施：數據庫提取數據的接口使用流水線接口，一次提取10-1000條數據，減小網絡RTT的時延；串行的單點瓶頸改成並行的程序；粗粒度的消息隊列改爲細粒度的；io改爲異步模式；輪詢的io或者多個io讀寫改爲epoll的多路複用檢測狀態。關鍵數據使用緩存服務，使用redis遠程緩存、靜態數據且多個程序調用緩存到共享內存，小量數據緩存到內存中。

使用性能檢測工具來定位，尋找最頻繁的調用和耗時來優化

使用inline或者宏替換函數調用，對於很是頻繁的調用也有不可忽視的性能提高

使用排好序的數據結構，幫助cpu作預判，也能提高性能