線程數究竟設多少合理

 1、需求緣起

Web-Server一般有個配置，最大工做線程數，後端服務通常也有個配置，工做線程池的線程數量，這個線程數的配置不一樣的業務架構師有不一樣的經驗值，有些業務設置爲CPU核數的2倍，有些業務設置爲CPU核數的8倍，有些業務設置爲CPU核數的32倍。

「工做線程數」的設置依據是什麼，到底設置爲多少可以最大化CPU性能，是本文要討論的問題。

 

2、一些共性認知

在進行進一步深刻討論以前，先以提問的方式就一些共性認知達成一致。

提問：工做線程數是否是設置的越大越好？

回答：確定不是的

1）一來服務器CPU核數有限，同時併發的線程數是有限的，1核CPU設置10000個工做線程沒有意義

2）線程切換是有開銷的，若是線程切換過於頻繁，反而會使性能下降

 

提問：調用sleep()函數的時候，線程是否一直佔用CPU？

回答：不佔用，等待時會把CPU讓出來，給其餘須要CPU資源的線程使用

不止調用sleep()函數，在進行一些阻塞調用，例如網絡編程中的阻塞accept()【等待客戶端鏈接】和阻塞recv()【等待下游回包】也不佔用CPU資源

 

提問：若是CPU是單核，設置多線程有意義麼，能提升併發性能麼？

回答：即便是單核，使用多線程也是有意義的

1）多線程編碼可讓咱們的服務/代碼更加清晰，有些IO線程收發包，有些Worker線程進行任務處理，有些Timeout線程進行超時檢測

2）若是有一個任務一直佔用CPU資源在進行計算，那麼此時增長線程並不能增長併發，例如這樣的一個代碼

 while(1){ i++; }

該代碼一直不停的佔用CPU資源進行計算，會使CPU佔用率達到100%

3）一般來講，Worker線程通常不會一直佔用CPU進行計算，此時即便CPU是單核，增長Worker線程也可以提升併發，由於這個線程在休息的時候，其餘的線程能夠繼續工做

 

3、常見服務線程模型

瞭解常見的服務線程模型，有助於理解服務併發的原理，通常來講互聯網常見的服務線程模型有以下兩種

IO線程與工做線程經過隊列解耦類模型

如上圖，大部分Web-Server與服務框架都是使用這樣的一種「IO線程與Worker線程經過隊列解耦」類線程模型：

1）有少數幾個IO線程監聽上游發過來的請求，並進行收發包（生產者）

2）有一個或者多個任務隊列，做爲IO線程與Worker線程異步解耦的數據傳輸通道（臨界資源）

3）有多個工做線程執行正真的任務（消費者）

這個線程模型應用很廣，符合大部分場景，這個線程模型的特色是，工做線程內部是同步阻塞執行任務的（回想一下tomcat線程中是怎麼執行Java程序的，dubbo工做線程中是怎麼執行任務的），所以能夠經過增長Worker線程數來增長併發能力，今天要討論的重點是「該模型Worker線程數設置爲多少能達到最大的併發」。

 

純異步線程模型

任何地方都沒有阻塞，這種線程模型只須要設置不多的線程數就可以作到很高的吞吐量，Lighttpd有一種單進程單線程模式，併發處理能力很強，就是使用的的這種模型。該模型的缺點是：

1）若是使用單線程模式，難以利用多CPU多核的優點

2）程序員更習慣寫同步代碼，callback的方式對代碼的可讀性有衝擊，對程序員的要求也更高

3）框架更復雜，每每須要server端收發組件，server端隊列，client端收發組件，client端隊列，上下文管理組件，有限狀態機組件，超時管理組件的支持

however，這個模型不是今天討論的重點。

 

4、工做線程的工做模式

瞭解工做線程的工做模式，對量化分析線程數的設置很是有幫助：

上圖是一個典型的工做線程的處理過程，從開始處理start到結束處理end，該任務的處理共有7個步驟：

1）從工做隊列裏拿出任務，進行一些本地初始化計算，例如http協議分析、參數解析、參數校驗等

2）訪問cache拿一些數據

3）拿到cache裏的數據後，再進行一些本地計算，這些計算和業務邏輯相關

4）經過RPC調用下游service再拿一些數據，或者讓下游service去處理一些相關的任務

5）RPC調用結束後，再進行一些本地計算，怎麼計算和業務邏輯相關

6）訪問DB進行一些數據操做

7）操做完數據庫以後作一些收尾工做，一樣這些收尾工做也是本地計算，和業務邏輯相關

 

分析整個處理的時間軸，會發現：

1）其中1，3，5，7步驟中【上圖中粉色時間軸】，線程進行本地業務邏輯計算時須要佔用CPU

2）而2，4，6步驟中【上圖中橙色時間軸】，訪問cache、service、DB過程當中線程處於一個等待結果的狀態，不須要佔用CPU，進一步的分解，這個「等待結果」的時間共分爲三部分：

2.1）請求在網絡上傳輸到下游的cache、service、DB

2.2）下游cache、service、DB進行任務處理

2.3）cache、service、DB將報文在網絡上傳回工做線程

 

5、量化分析併合理設置工做線程數

最後一塊兒來回答工做線程數設置爲多少合理的問題。

經過上面的分析，Worker線程在執行的過程當中，有一部計算時間須要佔用CPU，另外一部分等待時間不須要佔用CPU，經過量化分析，例如打日誌進行統計，能夠統計出整個Worker線程執行過程當中這兩部分時間的比例，例如：

1）時間軸1，3，5，7【上圖中粉色時間軸】的計算執行時間是100ms

2）時間軸2，4，6【上圖中橙色時間軸】的等待時間也是100ms

獲得的結果是，這個線程計算和等待的時間是1：1，即有50%的時間在計算（佔用CPU），50%的時間在等待（不佔用CPU）：

1）假設此時是單核，則設置爲2個工做線程就能夠把CPU充分利用起來，讓CPU跑到100%

2）假設此時是N核，則設置爲2N個工做現場就能夠把CPU充分利用起來，讓CPU跑到N*100%

 

結論：

N核服務器，經過執行業務的單線程分析出本地計算時間爲x，等待時間爲y，則工做線程數（線程池線程數）設置爲 N*(x+y)/x，能讓CPU的利用率最大化。

 

經驗：

通常來講，非CPU密集型的業務（加解密、壓縮解壓縮、搜索排序等業務是CPU密集型的業務），瓶頸都在後端數據庫，本地CPU計算的時間不多，因此設置幾十或者幾百個工做線程也都是可能的。

 

6、結論

N核服務器，經過執行業務的單線程分析出本地計算時間爲x，等待時間爲y，則工做線程數（線程池線程數）設置爲 N*(x+y)/x，能讓CPU的利用率最大化。

原文出自：架構師之路