0

我正在寻找开发高效 Web 服务器框架的解决方案，其中：

  1. 一个或几个 IO 线程处理客户端 HTTP 连接和 TCP IO。
  2. 多线程做业务处理（SQL查询、文件IO等）

我见过的所有博客解决方案都在解决 10000 个连接，工作线程几乎执行零业务逻辑（即仅使用async_write. Boost.Asio 的HTTP Server 3能解决我的问题吗？如果是这样，每个核心应该使用多少个线程？

我也有兴趣了解HTTP Server 3与mongoose使用的 1 个接受者线程 + 线程池模型的比较。

4

2 回答 2

1

抱歉，我没有足够的声誉来使用评论，所以我必须发布一个新的答案来提供任何意见。

OP 正在询问有关http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/http/server3/的具体问题。这是一个示例 http 服务器，它启动一个线程池来处理 http 请求。

OP 的原始问题可能会被重述：“给定具有一组资源 A 的服务器机器和每个请求消耗 B 资源的工作负载，我应该在线程池中分配多少线程？”

这里有一个线程：Reasonable number threads for thread pool running web service requests进行了类似的讨论（关于 Java 线程池），但该讨论似乎没有得出任何结论性的答案。

这是我在学校学到的“老式 1970 年代大型机风格”容量规划的简短教程示例：http ://www.cs.umb.edu/~eb/goalmode/primer.pdf 。

在这种情况下，您可能会创建一个简单的模型，例如：

You have an average rate of requests arriving, X. For each request you are consuming a certain average amount of cpu (in units of time) S_c, and an average amount of time spent waiting for disk requests to complete, S_d. So each thread is taking an average time S_c + S_d before it is returned to the thread pool. (You would need to measure this.) Thus on average you would expect that you would need at least N = X * (S_c+S_d) threads to avoid incoming threads queueing at an empty thread pool. You might actually want to allocate some small multiple of N (e.g. 3N) threads to be able to deal with bursts of one kind or another.

但是池中的线程数并不是真正有趣的限制。有趣的限制是您可用的 CPU 总量或磁盘带宽总量。假设每个请求需要 3 秒的 CPU 处理时间，并且您有一个具有 12 个内核的系统。因此，在任何 3 秒时间段内，您应该期望同时处理 12 个请求。因此，大于每秒 12/3 = 4 个请求的平均到达率会使您的 CPU 饱和。（磁盘带宽的类似计算。）

所以你最终要弄清楚的是：给定我预期的请求到达率 X，以及每个请求消耗的 CPU 和磁盘量，我应该购买多少 CPU 和磁盘？

于 2013-03-30T14:45:21.257 回答
0

After studying most of options , I have nearly come to conclusion
A] One thread for epoll
B] Pool for business logic
C] Queue between IO thread & pool
D] pipe between IO thread & pool to wake IO thread for write data
E] accept & client read & write be done by IO thread
And I guess ngix & lighthttpd follow same ?

于 2013-03-31T07:47:06.957 回答