http - 事件循环与多线程阻塞 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 机器或类似机器），您将通过多任务处理获得更好的性能。多任务可以是多线程阻塞模型，但也可以是收集传入请求的单任务事件循环，

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