TCP Server w/ boost::asio，线程池的可伸缩性与无堆栈的协同

Question

我正在构建一个基于TCP的守护进程，用于HTTP请求的前后处理。客户端将连接到Apache (或IIS)，一个自定义的Apache/IIS模块将将请求转发给我的TCP守护进程以进行进一步处理。我的守护进程需要扩展(但不是out)来处理大量的通信量，而且大多数请求都是小的和短暂的。守护进程将在C++中构建，必须是跨平台的。

目前，我正在研究boost asio库，这似乎是一种自然的适合。但是，我很难理解无堆栈协同与线程池模式的优点。具体来说，我在这里查看HTTP服务器示例#3和HTTP服务器示例#4：http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/examples.html

尽管我一直在谷歌搜索，但我无法完全理解无堆栈协同服务器的优点，以及它如何相对于多核系统上的线程池服务器执行任务。

考虑到我的要求，这两种方法中哪一种最合适，为什么？请随意“哑口无言”你的答案关于无堆叠的合作的想法，我仍然在这里摇摇欲坠。谢谢!

编辑：讨论的另一个随机想法/关注点: Boost HTTP示例#4被描述为“使用无堆栈协同机制实现的单线程服务器”。好吧，所以它完全是单线程的(对吗？)即使在父进程“分叉”给孩子之后？参见server.cpp中的示例#4)...will单线程成为多核系统的瓶颈？我假设任何阻塞操作都会阻止所有其他请求的执行。如果确实是这样的话，为了最大限度地提高吞吐量，我正在考虑一个基于协同的接收-数据异步事件，一个用于内部阻塞任务的线程池(用于利用多核)，然后是异步发送和关闭连接机制。同样，可伸缩性也是至关重要的。有什么想法吗？

Answer 1

我最近研究了boost.asio在多核机器上的可伸缩性。到目前为止的主要结论是，它确实引入了开销、锁争用和附加的上下文开关(至少在Linux上是这样)，请参阅我关于这些主题的一些博客文章：

• http://cmeerw.org/blog/748.html#748
• http://cmeerw.org/blog/751.html#751

我还在asio邮件列表上启动了一个线程，以检查没有遗漏任何明显的内容，请参阅http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133

如果您的主要关注点是性能和可伸缩性，那么恐怕没有明确的答案--您可能需要进行一些原型化并查看性能。

如果您有任何阻塞操作，那么您肯定希望使用多个线程--另一方面，上下文切换和锁定争用会降低多线程的性能(至少您必须非常小心)。

编辑：只是为了澄清无堆栈的协同功能:它本质上只是一些语法糖，以使异步API看起来更像顺序/阻塞调用。

Answer 2

由于很难预测引用的局部性、CPU指令缓存、调度延迟等的相对影响，您需要度量这些影响，以确定实际会发生什么。

如果要进行启发式猜测，请考虑使用堆栈大小为S的n个线程总是占用nS字节，不管每个线程实际使用的堆栈空间有多少。如果这推动您跨越页面边界，它可能会显著降低性能。