Event Loop vs Multithread阻塞IO

Question

我正在阅读有关服务器架构的评论。

http://news.ycombinator.com/item?id=520077

在这篇评论中，该人说了三件事：

1. 事件循环，一次又一次，已被证明真正为大量低活动连接发光。
2. 相比之下，与事件循环相比，一次又一次地显示了带有线程或进程的阻塞IO模型，以减少每个请求的延迟。
3. 在轻载系统上，差异难以区分。在负载下，大多数事件循环选择减速，大多数阻塞模型选择减少负载。

这些都是真的吗？

还有另一篇文章标题为“为什么事件是一个坏主意（对于高并发服务器）”

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Answer 1

通常，如果应用程序需要处理数百万个连接，则可以将多线程范例与基于事件的组合结合起来。

1. 首先，产生N个线程，其中N ==机器上的核心/处理器数量。每个线程都有一个它应该处理的异步套接字列表。
2. 然后，对于来自接受器的每个新连接，将新套接字“负载平衡”到具有最少套接字的线程。
3. 在每个线程中，为所有套接字使用基于事件的模型，以便每个线程可以“同时”实际处理多个套接字。

采用这种方法，

1. 你永远不会产生一百万个线程。您只需拥有系统可以处理的数量。
2. 您使用基于事件的多核而不是单核。

Answer 2

不确定“低活动”是什么意思，但我认为主要因素是你实际需要做多少来处理每个请求。假设有单线程事件循环，在处理当前请求时，没有其他客户端会处理其请求。如果你需要做很多事情来处理每个请求（“批量”意味着占用大量CPU和/或时间的东西），并假设你的机器实际上能够有效地进行多任务（花费时间并不意味着等待共享资源，如单个CPU机器或类似机器），您可以通过多任务处理获得更好的性能。多任务处理可以是一个多线程阻塞模型，但它也可以是一个单任务事件循环收集传入请求，将它们分配给多线程工作者工厂，这些工厂将依次处理这些工作（通过多任务处理）并尽快向您发送响应。

我不相信与客户端的缓慢连接非常重要，因为我相信操作系统会在您的应用程序之外有效地处理（假设您没有阻止事件循环与最初启动的客户端进行多次往返请求），但我自己没有测试过。