在單個事件循環中是否允許多個cURL多個句柄？

Question

我正在創建一個服務器，它將處理多個併發客戶端連接（大約100個），其中客戶端抽取大量數據和服務器包並將其發送到另一個遠程位置。

我想做的是將從每個客戶端發送的數據「分組」到他們自己的數據結構中（比如說一些鏈表），並且同時處理這些列表。吞吐量很重要，所以我希望能夠儘可能多地發送數據（可以說最多可同時處理10k個簡單的句柄）。

我想到的方法是：

1. 有一個大的線程池（比如100個線程），其中每個處理一個簡單的句柄。
2. 有一個單線程處理所有10k簡單句柄的多句柄。
3. 創建多個線程（如4）處理多個句柄，因此每個句柄處理2500個簡單的句柄。
4. 每個客戶端都有一個多處理器，因此每個處理一個多處理器的線程可能有100個。

我想知道的是，我是否可以'組合'＃2和＃3，使得我有一個線程可以在單個事件循環中處理多個多個句柄。這樣的事情是否允許，如果是的話，它會更有意義嗎？如果可能的話，它將滿足我對每個多句柄分組客戶端的要求，並且還可以讓我利用每個多句柄的持久連接。如果沒有，我完全利用所有客戶端的持續連接的唯一方法是選項＃4。最好我想減少使用的線程數量，這是由於我們所遵循的編程模型存在某些限制。

Answer 1

這是一個很複雜的問題，不可能簡單回答。它也將取決於很多當地條件和您可能具有的其他要求，但未在此處指定。我建議你建立一些原型，並針對你的特定條件對它們進行測量。

是：您可以使用多個多手柄在同一個線程，但它可能會變得有點古怪，我不認爲你會看到任何好處，而不是隻用一個，再添加全部輕鬆 - 處理那一個。

我個人的偏好是＃3，但也許會比4更多的線程，因爲如今您可以輕鬆擁有8個線程的CPU，並且很快就會有16個線程，而對於CPU佔用的情況，最好儘可能地分散負載以實現最高性能（但不要太高以獲得緩存和連接重用等）。另外，由於每個多重句柄然後處理N個簡單句柄，因此總是存在一定風險，即您必須爲特殊傳輸做些事情，這會使其他N-1傳輸暫停一點，然後它會更好如果你已經把總數分成了幾個線程，那麼它就不會阻止所有的傳輸。

最後，爲了達到這個速度，您可能需要使用基於事件的curl_multi_socket_action API來獲得最佳性能。