Http 事件循环与多线程阻塞IO

我正在读一篇关于服务器架构的评论

在这篇评论中，此人说了3件事：

事件循环一次又一次地显示，对于大量低活动连接，它确实非常出色

相比之下，一个带有线程或进程的阻塞IO模型已经被反复展示，与事件循环相比，它可以减少每个请求的延迟

在轻载系统上，差异是无法区分的。在负载下，大多数事件循环选择减速，大多数阻塞模型选择卸载

这些都是真的吗

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

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

---

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

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

首先，生成N个线程，其中N==机器上的内核/处理器数量。每个线程都有一个它应该处理的异步套接字列表

然后，对于来自接收器的每个新连接，“负载平衡”将新套接字连接到具有最少套接字的线程

在每个线程中，对所有套接字使用基于事件的模型，这样每个线程实际上可以“同时”处理多个套接字

用这个办法,

你永远不会产生一百万个线程。您的系统所能处理的数量就是这么多

您可以使用基于多核的事件，而不是单核

---

如果可能的话，你能提供一些具体的例子吗？谢谢使用QThreadPool和QRunnable很容易实现。检查这个答案需要整理一下。