※ 引述《StubbornLin (Victor)》之銘言： : 我最近正在考慮寫一個Server : 目前有考慮三種架構 : 1.輪詢式的架構 : 也就是單一迴圈 : 不停的更新所有連線的狀態並做出回應 : 2.MultiThread : 每個連線都由一個Thread負責 : 3.混合式 : 混合輪詢和MultiThread式，每個Thread負責一定數量的連線 : 目前我只有寫過輪詢式的，其它兩種都沒寫過 : 考慮到效能，輪詢式的在連線數很多時，很明顯的一個問題就是 : 當連線數到一定數量時，可能會變得很沒效率 : 每個連線如果花1ms，1000個連線就是1秒 : 但是如果以MultiThread來執行，可以充份利用CPU的資源 : 可是這又帶來另一個問題，由於我對Thread的成本不太了解，用起來還是會怕怕的 : * 其中一個問題就是，我不了解開一個Thread到底需要多少成本? : 接著，我想到如果1000個連線就要開1000個Thread : 而Thread的成本如果讓人難以接受的話，那可能就得考慮第三種 : 混合式的，每個Thread負責一定數量的連線 : 但是又帶來另一個問題就是設計上會變得有點複雜 : ---------------------------------------------------------------- : 除此之外還有另一個我不了解的地方，就是 : * 多核心的CPU到底對效能上的改進有多少幫助? : 最近多核心的CPU在市面上似乎成為主流，但是我一直很好奇 : * 就運作上，到底能將工作分配給不同核心做到什麼地步? : 以上，是我的問題 我用 Windows 的觀點來回答你，第一個方式會在連線變多的時候，效率大幅度下降， 第二個方式會因為 context switch 導致 cpu 都在處理 thread 與 thread 之間的 關係而大幅度飆漲，第三個方式，是你提出的三個方式之中最有效率的。 第三個方式大概等於 Windows 中使用 WSAEventSelect 的情況， 因為 Windows 也限制一個 WSAWaitForMultipleEvents 最多等待 WSA_MAXIMUM_WAIT_EVENTS 個 event handle(也就是 64 個), 所以組合起來的情況 就是你提的第三個方式。 此種方式大致上運作良好，但是也是會在大量連線的情況下，因為 context switch 而導致效能直線下降。 而最好的方式是什麼？ 目前我所知道最好的方式就是非同步IO。 在 Windows 底下就是使用 I/O completion port，也就是 overlapped I/O 更進一階 Windows 將在 kernel 使用 thread pool 來幫你處理 I/O，並且有效率的管理 thread pool 的 thread 數量，讓你在多 cpu 的時候可以充分利用到 cpu。 即使你在大量的連線情況下，也不會用到太多的 thread。 不過，你就要開始擔心 locked pages limit 跟 non-paged pool limit，但這是另外 一個故事了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.105.117.50