为什么多线程文件传输提高了性能?

该工具在硬件方面进行了改进,可以更好地优化多个读写请求。

当一次复制一个文件时,硬件将不知道当前在读取头(或附近)下传递的数据块将需要子序列读取,因为软件尚未将该请求排队。

对于现代的磁盘子系统来说,现在的单个文件拷贝并不是很繁重的任务。通过给这些硬件系统更多的工作,该工具可以利用其改进的优化功能。

一个简单的“复制多个文件”应用程序将复制一个文件,然后在复制下一个文件之前等待该文件完成。

这意味着即使单个文件为空(0字节),也无法以比网络延迟更快的速度复制该文件。因为它可能会执行多个文件服务器调用(打开、写入、关闭),这可能是延迟的几倍。

为了有效地复制文件,您需要一个服务器和客户机使用一个健全的协议,该协议具有流水线;也就是说,客户机在发送下一个文件之前不会等待保存第一个文件,而且实际上,多个或多个文件可能同时处于“在线”状态。

当然,要做到这一点,需要一个自定义服务器,而不是一个SMB(或类似的)文件服务器。例如,rsync可以做到这一点,并且非常擅长复制大量文件,尽管它是单线程的。

所以我的猜测是多线程有帮助,因为服务器不支持在单个会话上进行流水线操作这一事实需要解决。

在我看来,使用合理协议的单线程实现最好。

它是一个网络工具,所以瓶颈是网络,而不是硬盘。在一个(低)点上,通过并行使用几个连接,可以从TCP链路获得更多的吞吐量。这(a)与TCP握手并行;(b)如果带宽延迟积很高,则可以更好地利用带宽延迟积;以及(c)如果由于某种原因遇到高RTT或故障率,则不会使任意慢速连接成为关键路径。

另一种方法是使用一个巨大的TCP套接字接收缓冲区,但这并不总是方便的。

关于HDD的其他几个答案是错误的。实际上,任何HDD都会在假定顺序访问的情况下进行一些预读,而任何智能OS缓存也会这样做。

我猜HDD读写头大部分时间都是空闲的,等待磁盘的正确内存块到达它们下面,复制的内存越多意味着空闲时间越短,大多数现代磁盘调度程序应该处理跳跃(对于数量较少的文件/碎片)

据我所知,在现代计算机系统上复制文件时,硬盘是瓶颈,而不是CPU或网络。

我认为这些假设过于简单化了。

首先,当局域网以100MB/1Gbit的速度运行时。长途网络的最大数据速率小于最慢链路的最大速率。

其次,TCP/IP流在Internet上的有效吞吐量通常由往返消息和确认所花费的时间决定。例如,我有一个8+mbit的链接,但是当我从美国下载时,我的数据下载速率很少超过1-2比特/秒。因此,如果你可以并行运行多个流,一个流可以等待确认,而另一个流则在发送数据包。(但是如果你试图发送过多的邮件,你就会开始出现拥塞、超时、退后和整体传输率降低。)

最后,操作系统擅长与其他工作并行执行各种I/O任务。如果您并行下载两个或多个文件,O/S可能正在为一个下载读取/处理网络包,并为另一个下载写入磁盘…同时。

在长距离传输中,网络的写入速度比其读取速度快得多。对于多线程,拥有额外的“读卡器”意味着可以更有效地传输数据,而不会陷入缓冲区。