TNonblockingServer，TThreadedServer和TThreadPoolServer，哪一個最適合我的情況？

Question

我們的分析服務器是用C++編寫的。它基本上查詢底層存儲引擎，並通過節儉返回相當大的結構化數據。典型的請求將需要大約0.05到0.6秒才能完成取決於請求大小。

我注意到我們可以在C++代碼中使用的Thrift服務器有幾個選項，特別是TNonblockingServer，TThreadedServer和TThreadPoolServer。看起來像TNonblockingServer是一條路，因爲它可以支持更多的併發請求，並且仍然使用場景後面的線程池來處理任務。它也避免了構造/破壞線程的成本。

Facebook的節儉更新：http://www.facebook.com/note.php?note_id=16787213919

在這裏，在Facebook上，我們是完全異步客戶端和服務器上工作了C++。這 服務器使用像目前TNonblockingServer事件驅動I/O，但其 應用程序代碼的接口都是基於異步回調。這將允許我們寫一個可以服務於數以千計的併發請求的 服務器（每個需要 打電話給其他儲蓄或內存緩存服務器），只有少數線程。

上stackover相關文章：Large number of simulteneous connections in thrift

話雖這麼說，你也不一定能真正做到提高工作效率（處理 線程池中仍然執行），但更多的客戶會能夠立即連接到你。

只是想知道是否有其他的因素，我在這裏失蹤？我怎樣才能決定哪一個最適合我的需求？

Answer 1

請求採取50-600毫秒才能完成相當長。創建或銷燬線程所花費的時間遠遠少於此，所以請不要將此因素納入當前的決策。我會選擇一個最容易支持的，而且這是最不容易出錯的。您希望最小化微妙的併發錯誤的可能性。

這就是爲什麼它是塊需要的地方往往更容易編寫單線程事務處理的代碼，並有許多這樣的並行運行，而不是有一個更復雜的非阻塞模式。被阻塞的線程可能會降低單個事務的速度，但它不會阻止服務器在等待時執行其他工作。

如果您的事務負載增加（即更多的客戶端事務）或請求變得更快（每個事務接近1毫秒），則事務開銷將變成更重要的因素。需要注意的指標是吞吐量：每單位時間完成多少事務。單次交易的絕對持續時間並不比完成交易的時間重要，至少如果持續低於一秒鐘的話。

Answer 2

一個上Github傢伙已經打了一個漂亮的比較

TThreadedServer

TThreadedServer派生爲每個客戶端連接一個新的線程，直到客戶端連接被關閉每個線程仍然活着。這意味着如果有1000個併發客戶端連接，TThreadedServer需要同時運行1000個線程。

TNonblockingServer

TNonblockingServer具有專門用於網絡I/O一個線程。同一個線程也可以處理請求，或者可以爲請求處理創建一個單獨的工作線程池。服務器可以使用少量線程處理多個併發連接，因爲它不需要爲每個連接產生一個新線程。

TThreadPoolServer（此處未基準）

TThreadPoolServer類似於TThreadedServer;每個客戶端連接都有自己的專用服務器線程。它與TThreadedServer有兩種不同之處：

客戶端關閉連接以供重用時，服務器線程返回到線程池。 線程數有限制。線程池不會超出限制。 如果線程池中沒有更多線程可用，則客戶端將掛起。與其他2臺服務器相比，使用起來要困難得多。