针对 Boost ASIO 的设计，用于 Web 服务器的工作线程 SQl 查询'practical'

Design for Boost ASIO , Worker threads SQl queries for 'practical' web server

本文关键字：线程 SQl practical 工作查询 Web ASIO Boost 针对用于服务器更新时间：2023-10-16

我正在寻找解决方案，开发一个高效的web服务器框架，其中:

一个或几个IO线程处理客户端HTTP连接和TCP IO。
多个线程进行业务处理(SQL查询，文件IO等)

我看到的所有博客解决方案都是用工作线程解决10000个连接，几乎没有业务逻辑(即只是使用async_write写数据)。是助推。Asio的HTTP服务器3解决我的问题?如果是的话，每个核应该使用多少线程?

我也有兴趣知道HTTP Server 3与mongoose使用的1受体线程+线程池模型相比如何。

对不起，我没有足够的声誉来使用评论，所以我必须发布一个新的答案来提供任何输入。

开口保险单是问一个关于http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/http/server3/的具体问题。这是一个示例http服务器，启动一个线程池来处理http请求。

开口保险单最初的问题可以重述一下:"给定一台服务器机器，它有一组资源a，工作负载每个请求消耗B个资源，我应该在线程池中分配多少个线程?"

这里有一个线程:运行web服务请求的线程池的合理线程数与类似的讨论(关于Java线程池)，但该讨论似乎没有得出任何结论性的答案。

下面是我在学校里学到的一个关于"70年代老式大型机风格"容量规划的简短教程: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和磁盘?

在研究了大部分选项之后，我几乎得出了结论
一个线程的epoll
业务逻辑池
C] IO线程之间的队列;池
D] IO线程之间的管道&为写数据唤醒IO线程的池
E]接受;客户端读取&写操作由IO线程完成
我猜ngix &