聊聊高併發下效能

效能決定程式流暢性，流暢性對於使用者體驗有著重要影響，試著想一下多少次是因為一個網站反應慢就離開了網站，app響應慢就把app關了，並且有時是你特別急需一件事情要做的時候，偏偏他就不肯響應。

今天雖然cpu越執行越快，但是我們程式規模卻也變得越來越大，消耗完了cpu新給我們增加的計算量。

決定程式效能主要有幾個因素，我們程式對於cpu的使用，程式對於記憶體使用，程式對於網路使用。當然還有磁碟等其他外部因素，主要的應該是前邊這幾項，優化就是要從這幾個方向入手。

機器或者容器cpu、記憶體佔用過高，比如80%以上程式本身計算原來相同任務就需要比以前更長時間。導致程式響應速度變差，這個是我們用桌上型電腦或者筆記本執行一些大型程式經常遇到的問題。

但是我們不能為了讓程式執行變快，變讓機器長期處在比較閒的狀態，比如cpu長期只用了1%或以下，舉的例子極端一些。作為提供計算服務的機器我們應該讓他cpu、記憶體處在一個比較合理水平，這樣既增加了資源利用，線上程式又是能在比較好的外部資源情況下執行。

聊聊cpu層面，從cpu層面需要我們我們程式指令越少越好，指令越少意味著執行的越快，指令越簡單越好，越簡單指令執行越快，越複雜指令執行越慢。

聊聊記憶體層面，記憶體佔用越小越好，算法佔用儲存空間越小越好。

實際情況總會更復雜，經常需要通過空間換時間，比如快取，作業系統快取、應用程式快取、瀏覽器快取、app快取、服務端快取等等。經常會通過佔用更大空間來讓程式執行的更快。

演算法時間複雜，時間複雜度越低說明程式執行越快。當演算法優化達到瓶頸後，就要通過多執行緒、多程序等技術來提升計算速度。

使用多執行緒也會帶來新的問題，多執行緒多少合適，執行緒有沒有不夠用，執行緒有沒有過多 ，執行緒合併問題，任務被拒絕問題。多執行緒本身是一種優化效能手段，但比如運用執行緒池時多少時能夠既不讓過多執行緒閒置，也沒有讓有任務執行不過來或者任務被拒絕或長時間等待，因為線上服務一般響應時間為100ms以內過長時間等待任務就沒有意義了。

多執行緒還存在一個多個執行緒合併問題，通過countdown等方式可以進行任務同步，但是任務分拆是有消耗的，個別任務超時後邏輯怎麼做以及超時後監控或重做都是需要仔細思索的問題。

效能優化還可以利用分散式計算多個機器多個執行緒計算，然後由merge節點合併多個機器計算結果，問題是多個機器節點存在io消耗，多個機器再分執行緒也存在消耗，最後還要合併到merge，merge也是存在時間消耗。

效能優化有許許多多方式，但需要我們對整體io、執行緒構建、同步等多個因素綜合考慮，通盤去想，並且需要對整個部署方式比如容器還是物理機以及網路耗費整體思考，優化時要考慮到整體避免顧此失彼，所以效能優化需要對體系整體有認知並且需要不斷嘗試。