我有一个 FTP 服务器，在 QTcpServer 和 QTcpSocket 之上实现。
我利用信号和槽机制同时支持多个 TCP 连接，即使我只有一个线程。我的代码尽快返回到事件循环，它不会阻塞（没有等待函数），并且它不会在任何地方使用嵌套事件循环。这样我就已经有了协作式多任务处理，就像 Win3.1 应用程序一样。
但是很多其他的 FTP 服务器都是多线程的。现在我想知道使用单独的线程处理每个 TCP 连接是否会提高性能，尤其是 延迟。
一方面，线程会增加延迟，因为您需要为每个新连接启动一个新线程，但另一方面，在我的协作多任务处理中，其他 TCP 连接必须等到我之前返回到主循环可以处理他们的readyRead()/bytesWritten() 信号。
【问题讨论】：
标签： multithreading qt latency qtcpsocket
在您当前的系统中并忽略文件 I/O 时间，如果有什么有用的事情要做，一个处理器总是在做一些有用的事情，如果没有什么有用的事情要做，那么它会等待准备就绪。如果这是一个单处理器（单核）系统，您将获得最大的吞吐量。这通常是一个非常好的设计——尤其是对于一个 FTP 服务器，在这种服务器上，您通常没有人在逐个数据包地等待。
您还最小化了平均延迟（对于单处理器系统）。您没有的是一致延迟。衡量您的系统性能可能会显示很多抖动——处理数据包所需的时间有很多变化。同样，因为这是 FTP，而不是实时过程控制或人工交互，所以抖动可能不是问题。
现在，请考虑您的系统上可能有多个处理器可用，并且可能会重叠 I/O 时间和处理时间。
要充分利用多处理器（核心）系统，您需要一些并发性。
这通常转化为使用多个线程，但也可以通过异步（非阻塞）文件读取和写入来实现并发。
但是，向程序中添加多个线程会打开一个巨大的蠕虫罐。
如果您决定采用 MT 路线，我建议您考虑依赖线程感知 I/O 库。 QT 可能会为您提供（我不确定。）如果没有，请查看 boost::asio （或 ACE 用于较旧但仍然可靠的解决方案）。您会发现使用此类库的 MT 功能需要对学习时间进行大量投资；然而，事实证明，“手动”添加多线程并使其正确的时候会更糟。
所以我会说保留现有的解决方案，除非您担心未使用的处理器周期和/或抖动，在这种情况下开始学习 QT 的多线程支持或 boost::asio。
【讨论】：
您是否需要为每个新连接启动一个新线程？你能不能只有一个线程池在请求到达时对请求起作用。这应该会减少一些延迟。我不得不说，一般来说，多线程 FTP 服务器应该比单线程服务器响应更快。是否可以有一个基于事件的 FTP 服务器？
【讨论】：