最高效的高性能服務器套接字/線程設計

我正在構建一個性能極高的企業軟件，它將接收，處理和響應每秒超過50,000個TCP請求。這將分散在許多亞馬遜EC2服務器上，但我想要一臺服務器能夠處理儘可能多的每秒請求數千次（拍攝速度爲5k /秒）。我很可能會使用運行Amazon Linux的m1.xlarge實例。最高效的高性能服務器套接字/線程設計

我使用Boost ASIO在C++中構建了這個軟件，我試圖找出構建套接字處理的最有效方法。在示例中（http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/examples.html），我傾向於模擬「HTTP服務器2」，因爲我們將有多個vCPU給員工。

有人能真正描述每個HTTP服務器示例的優缺點，並處理這麼多的連接，我真的很感激任何額外的洞察（關於Boost套接字和/或高吞吐量EC2配置）。

非常感謝！

來源

2013-06-28 Harry

雖然每秒50k消息並不完全消失，但我不會稱之爲「極高性能」。 http://www.marketdatapeaks.com/ –

對我來說，這是非常高的性能。當然，這不是股票市場規模（當然還有很多其他公司處理更大的數量），但是每個50k請求在後端都有相當數量的處理（不僅僅是服務於靜態文件），所以我認爲它相當密集。你有任何這樣的經驗嗎？謝謝！ – Harry

我確實，但不幸的是，我不知道你引用的例子。 –

您可能希望查看非阻塞套接字並將輸入/輸出/處理分散到不同的線程中。每千個連接可能創建3個新的輸入/輸出/處理線程？

希望有所幫助。

來源

2013-06-29 06:20:25

一些建議：

你沒有提到你的服務器將要做什麼。它會每秒接受和關閉50K個新請求，還是隻處理來自建立的TCP連接的消息（請求）。所以我的建議可能必須是通用的。

閱讀C10K問題：http://www.kegel.com/c10k.html
投資使用epoll的作爲插座通知解決方案，而不是ASIO。 epoll並不難。
考慮使用固定數量的線程（2-8）。既可以對這些線程間的套接字連接進行負載平衡，也可以僅使用線程工作池來處理從套接字線程解析出來的請求消息。設計多線程，但從使用1個線程開始。然後解決所有性能問題。一旦你獲得了單線程解決方案的良好運行，並且性能處於最佳狀態，那麼可以考慮增加線程數，以便在其他線程被阻塞的同時可以處理多個操作。
您的服務器的性能問題將超出套接字設計的可能性非常高。不斷進行基準測試並運行諸如valgrind之類的工具，以瞭解代碼花費大部分時間。機會很高，這是你最不期待的地方。例如，在我的服務器上，我發現大部分時間都花在爲小臨時緩衝區分配和釋放內存上。我永遠不會猜到這一點。然後，我改變了服務器設計，先分配內存，使用堆棧內存等......這樣處理請求永遠不需要代碼分配內存。當我做出改變時，性能容易翻倍。

來源

2013-06-29 07:51:36 selbie

提升asio應該使用epoll，請參閱http://stackoverflow.com/questions/3106304/boost-asio-on-linux-not-using-epoll – mark

在我的optinion目前沒有C10K的問題，這個鏈接也是高估..最近我把我們的項目從自寫的epoll反應器移到ASIO。現在它可以管理10倍以上的連接，並且不會落後於每個客戶端; TLS在手動庫使用方面的表現也非常好;現在所有的服務器定時器都是異步的，與epoll版本相反（對定時器沒有任何限制）。異步應用程序不僅是epoll，它是定時器，越野車客戶和許多其他的東西，你只會在生產中學習 – PSIAlt

最高效的高性能服務器套接字/線程設計

回答

相關問題