在一个单独的线程中处理每个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服务器吗？