為Boost ASIO設計，Worker線程對“實用” Web服務器進行SQl查詢

Question

我正在尋找解決方案以開發高效的Web服務器框架，其中：

1. 一個或幾個IO線程處理客戶端HTTP連接和TCP IO。
2. 多個線程進行業務處理（SQL查詢，文件IO等）

我看到的所有博客解決方案都在解決與工作線程建立的10000個連接，這些線程幾乎執行零業務邏輯（即僅使用async_write寫入數據）。 Boost.Asio的HTTP Server 3是否可以解決我的問題？ 如果是這樣，每個內核應使用多少個線程？

我也有興趣知道如何HTTP Server 3的比較所使用的1個受體線程+線程池模型貓鼬 。

Answer 1

抱歉，我沒有足夠的聲譽來使用評論，所以我必須發布一個新答案以提供任何輸入。

OP正在詢問有關http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/http/server3/的特定問題。 這是一個示例http服務器，它啟動一個線程池來處理http請求。

OP的原始問題可能會被重申：“如果一台服務器計算機具有一組資源A和每個請求消耗B資源的工作負載，那么我應該在線程池中分配多少個線程？”

這里有一個線程： 用於運行Web服務請求的線程池的線程數量合理，討論類似（關於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和磁盤？

Answer 2

在研究了大多數選項之后，我幾乎得出結論了
A] epoll的一個線程
B]業務邏輯池
C] IO線程和池之間的隊列
D] IO線程和池之間的管道，以喚醒IO線程以寫入數據
E]接受和客戶端讀寫由IO線程完成
我猜ngix和lighthttpd遵循相同嗎？