事件循环与多线程阻塞IO

Question

我读到了一篇关于服务器架构的评论。

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

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

事件循环一次又一次地证明，对于高数量的低活动connections.

• In比较来说，事件循环是真正的亮点，一次又一次地显示了一个带有线程或进程的阻塞IO模型，与事件循环相比，在每个请求的基础上减少延迟。在一个负载较轻的系统上，

• 是无法区分的。在负载下，大多数事件循环选择减速，大多数阻塞模型选择释放负载。

这些都是真的吗？

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

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

Answer 1

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

1. 首先，生成N个线程，其中机器上有N个==核/处理器。每个线程都会有一个异步套接字列表，它应该处理这些套接字。然后，对于来自受体的每个新连接，“负载平衡”--新套接字到最少套接字的线程。在每个线程中，对所有套接字使用基于事件的模型，以便每个线程能够实际处理多个套接字( "simultaneously."

)。

用这种方法，

1. 你从来没有产生过一百万个线程。您只有尽可能多的系统处理。
2. 您使用基于多核的事件，而不是单个核。

。

Answer 2

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

我不认为与客户端的缓慢连接有多大关系，因为我相信操作系统会在应用程序之外有效地处理这个问题(假设您没有阻止事件循环，以便与最初发起请求的客户端进行多次往返)，但我本人还没有进行测试。