在单独的线程中处理每个TCP连接会改善延迟吗？

Question

我有一个FTP服务器，在QTcpServer和QTcpSocket之上实现。

我利用信号和插槽机制同时支持多个TCP连接，即使我有一个线程。我的代码尽快返回到事件循环，它不会阻塞（没有等待函数），并且它不会在任何地方使用嵌套的事件循环。这样我就已经拥有合作多任务，就像Win3.1应用程序一样。

但是很多其他FTP服务器都是多线程的。现在我想知道使用单独的线程来处理每个TCP连接是否会提高性能，尤其是延迟。

一方面，线程增加了延迟，因为你需要为每个新连接启动一个新线程，但另一方面，通过我的协作式多任务处理，其他TCP连接必须等到我回到主循环之前可以处理他们的readyRead() / bytesWritten()信号。

Answer 1

在你当前的系统中并且忽略文件I / O时间，如果有一些有用的事情可以做，那么一个处理器总是做一些有用的事情，如果没有什么有用的东西可以等待准备好。如果这是一个单处理器（单核）系统，您将获得最大化的吞吐量。这通常是一个非常好的设计 - 特别是对于FTP服务器而言，您通常不会在逐个数据包的基础上等待人员。

您还最小化了平均延迟（针对单处理器系统。）您没有的是一致延迟。衡量系统性能可能会显示很多 抖动 - 处理数据包所需的时间差异很大。再次因为这是FTP而不是实时过程控制或人工交互，抖动可能不是问题。

现在，请注意您的系统上可能有多个处理器，并且可能会重叠I / O时间和处理时间。

要充分利用多处理器（核心）系统，您需要一些并发性。

这通常转换为使用多个线程，但可以通过异步（非阻塞）文件读取和写入来实现并发。

但是，向程序添加多个线程会打开一个巨大的蠕虫病毒。

如果您决定采用MT路由，我建议您考虑依赖于线程感知的I / O库。 QT可能会为您提供（我不确定。）如果没有，请查看boost :: asio（或ACE，以获取较旧但仍然可靠的解决方案）。你会发现使用这种图书馆的MT功能需要花费大量的学习时间;然而，事实证明是时候“手动”添加多线程并且做得更好更糟糕。

所以我要说保留你现有的解决方案，除非你担心未使用的处理器周期和/或抖动，在这种情况下开始学习QT的多线程支持或者boost :: asio。

Answer 2

您是否需要为每个新连接启动一个新线程？难道你不能只有一个线程池，当它们到达时会对请求起作用。这应该减少一些延迟。我不得不说，一般来说，多线程FTP服务器应该比单线程服务器响应更快。是否可以拥有基于事件的FTP服务器？