※ 引述《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