我有一個FTP服務器，在QTcpServer和QTcpSocket之上實現。在單獨的線程中處理每個TCP連接會提高延遲嗎？
予取信號和槽機制同時支持多個TCP連接的優點，即使我有一個單一的線程。我的代碼儘快返回到事件循環，它不會阻塞（不等待函數），並且它不會在任何地方使用嵌套的事件循環。這樣我已經有了合作多任務，就像Win3.1應用程序一樣。
但很多其他FTP服務器是多線程的。現在我想知道是否使用單獨的線程來處理每個TCP連接會提高性能，尤其是延遲。
一方面，線程會延遲等待時間，因爲您需要爲每個新連接啓動一個新線程，但另一方面，通過協作式多任務處理，其他TCP連接必須等到我返回主循環在它們的readyRead()/bytesWritten()信號可以被處理之前。
在你當前的系統，而忽略文件I/O時間一個處理器總是在做一些有用的事情，如果有做有用的東西，並等待隨時可以去，如果有什麼工作要做有用的。如果這是一個單處理器（單核）系統，那麼你將會使吞吐量達到最大化。這通常是一個非常好的設計 - 特別是對於一個通常不會有人在等待每個數據包的FTP服務器的情況。
你也降到最低平均延遲（用於單處理器系統。）你不必是一致延遲。測量你的系統的性能可能會表現出很多抖動的 - 很多的時間變化的需要處理的數據包。再次因爲這是FTP而不是實時過程控制或人爲交互，抖動可能不成問題。
現在，但認爲有可能是你的系統上可用一個以上的處理器，並且有可能重疊I/O時間和處理時間。
要充分利用多處理器（核心）系統，您需要一些併發性。
這通常轉換爲使用多線程，但它可以是能夠實現經由異步（非阻塞）併發文件的讀取和寫入。
但是，向程序中添加多個線程會引發巨大的蠕蟲病毒。
如果你決定去MT的路線，我建議你考慮取決於線程感知I/O庫。 QT可能會爲你提供（我不確定）。如果沒有，請查看boost :: asio（或者對於較老的但仍然可靠的解決方案的ACE）。你會發現，使用這種圖書館的MT功能需要在學習時間上進行相當大的投資;然而，事實證明，「手動」添加多線程的時間並沒有改變，甚至更糟。
所以我說留與現有的解決方案，除非你是擔心未使用的處理器週期和/或抖動在這種情況下開始學習QT的多線程支持或提高:: ASIO。
是否需要爲每個新連接啓動一個新線程？您是否可以不只是有一組線程在請求到達時作用於請求。這應該會減少一些延遲。我不得不說，一般來說，多線程FTP服務器應該比單線程服務器響應更快。是否有可能有一個基於事件的FTP服務器？
提高 「潛伏」？沒有。提高「響應能力」？只有當你讀取時才被阻止;並且套接字I/O會阻止您的用戶界面。這似乎並不是這種情況。 – paulsm4 2013-02-26 17:36:08