我正在寻找开发高效Web服务器框架的解决方案，其中：
我所见过的所有博客解决方案都是通过工作线程解决10000个连接，几乎没有业务逻辑（即只使用async_write编写数据）。 Boost.Asio的HTTP Server 3是解决我问题的方法吗？如果是这样，每个核心应该使用多少个线程？
我也很想知道HTTP Server 3与mongoose使用的1接受者线程+线程池模型的比较。
答案 0 :(得分：1)
抱歉，我没有足够的声誉来使用这些评论，所以我必须发布一个新的答案来提供任何意见。
O.P。正在询问有关http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/http/server3/的具体问题。 这是一个示例http服务器，它启动一个线程池来处理http请求。
O.P.的原始问题可能会被重述：“如果服务器机器具有一组资源A，并且每个请求消耗B资源的工作负载，我应该在线程池中分配多少个线程？”
这里有一个帖子：Reasonable number of threads for thread pool running web service requests有类似的讨论（关于Java线程池），但讨论似乎没有得出任何结论性答案。
以下是我在学校学到的“老式的1970年代大型机风格”中的容量规划简短教程示例：http://www.cs.umb.edu/~eb/goalmode/primer.pdf。
在这种情况下，您可以创建一个简单的模型，如：
您有平均请求率，X。对于每个请求，您正在消耗一定数量的cpu（以时间为单位）S_c，以及等待磁盘请求完成所花费的平均时间，S_d。因此每个线程在返回线程池之前需要平均时间S_c + S_d。 （您需要对此进行测量。）因此，平均而言，您可能希望至少需要N = X *（S_c + S_d）个线程来避免传入的线程在空线程池中排队。实际上，您可能希望分配一些N（例如3N）线程的小数，以便能够处理这种或那种突发。
但是池中的线程数并不是真正有趣的限制。有趣的限制是CPU的总量或可用的磁盘带宽总量。假设每个请求需要3秒的CPU处理，并且您拥有一个具有12个内核的系统。因此，在任何3秒的时间内，您应该期望处理12个同时请求。因此，平均到达率大于12/3 =每秒4个请求会使CPU饱和。 （类似的磁盘带宽计算。）
因此，您最终要弄清楚的是：考虑到我的预期到达请求率，X以及每个请求消耗的CPU和磁盘数量，我应该购买多少CPU和磁盘？
答案 1 :(得分：0)
在研究了大多数选项后，我几乎得出结论
A] epoll的一个帖子
B]业务逻辑池
C] IO线程和放大器之间的队列游泳池
D] IO线程与管道之间的管道池唤醒IO线程以写入数据
E]接受＆amp;客户阅读＆amp;写入由IO线程完成
我想ngix＆amp; lighthttpd跟着一样？