Re: [問題] Server的架構
※ 引述《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
討論串 (同標題文章)
Programming 近期熱門文章
PTT數位生活區 即時熱門文章