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

Question

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

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

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

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

Answer 1

在您当前的系统中，如果没有什么有用的事情，一个处理器总是在做有用的事情，而在没有任何有用的事情的情况下，则等待准备就绪。如果这是一个单处理器(单核)系统，那么您将获得最大的吞吐量。这通常是一个非常好的设计-特别是对于FTP服务器，在该服务器上通常没有人在逐个数据包的基础上等待。

您还最小化了平均延迟(对于单处理器系统。)您没有的是一致的延迟。衡量系统性能可能会显示很多抖动-处理数据包的时间有很多差异。同样，由于这是FTP，而不是实时过程控制或人工交互，因此抖动可能不是问题。

现在，请考虑一下，系统上可能有多个处理器可用，并且可能有重叠的I/O时间和处理时间。

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

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

但是，在程序中添加多个线程会带来巨大的蠕虫病毒。

如果您决定走MT路线，建议您考虑依赖线程感知的I/O库。 QT可能会为您提供(我不确定。)否则，请看一下boost::asio(或者对于较旧但仍然可靠的解决方案，请使用ACE)。您会发现使用这样一个库的MT功能会花费大量的学习时间。但是，事实证明，“手动”添加多线程并使其正确的时间更加糟糕。

因此，除非您担心未使用的处理器周期和/或抖动，否则我将继续使用现有解决方案，在这种情况下，您将开始学习QT的多线程支持或boost::asio。