12

我正在构建一个基于 TCP 的守护进程，用于 HTTP 请求的预处理/后处理。客户端将连接到 Apache HTTPD（或 IIS），并且自定义 Apache/IIS 模块会将请求转发到我的 TCP 守护程序以进行进一步处理。我的守护进程需要扩展（但不是扩展）以处理大量流量，并且大多数请求都是小而短暂的。守护程序将使用 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 被描述为“使用无堆栈协程实现的单线程 HTTP 服务器”。好的，所以它完全是单线程的（对吗？即使在父进程“分叉”给子进程之后？参见示例 #4 中的 server.cpp）……单线程会成为多核系统的瓶颈吗？我假设任何阻塞操作都会阻止所有其他请求执行。如果确实如此，为了最大限度地提高吞吐量，我正在考虑一个基于协程的接收数据异步事件，一个用于我的内部阻塞任务的线程池（以利用多核），然后是一个异步发送和关闭连接机制。同样，可扩展性至关重要。有什么想法吗？

4

2 回答 2

9

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

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

如果您主要关心的是性能和可扩展性，那么恐怕没有明确的答案 - 您可能需要进行一些原型设计并查看性能。

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

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

于 2012-05-12T21:12:23.227 回答
0

由于难以预测参考位置、CPU 指令缓存、调度延迟等的相对影响，您需要测量影响以确定实际会发生什么。

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

于 2012-05-11T15:03:20.677 回答