Windows - 通过"localhost"访问数据会导致网络堆栈开销

Clo*_*oud 10 windows localhost network-share network-shares

我有大量的音频文件,我通过处理算法运行,试图从中提取某些数据(即:整个剪辑的平均音量).我有许多构建脚本,以前从Samba网络共享中提取输入数据,我已经创建了一个映射到via net use(即:)的网络驱动器M: ==> \\server\share0.

现在我有一个新的大型1TB SSD,我可以在本地存储文件并快速处理它们.为了避免大量重写我的处理脚本,我删除了网络驱动器映射,并使用localhost主机名重新创建它.即:M: ==> \\localhost\mydata.

当我使用这样的映射时,我是否有可能产生大量开销,例如数据必须通过Windows网络堆栈的一部分,或者操作系统是否使用任何快捷方式,因此它或多或少等于直接磁盘访问(即:机器知道它只是从自己的硬盘驱动器中提取文件).增加的延迟并不是我的担忧,但最大的持续平均吞吐量至关重要.

我问这个是因为我决定是否应该修改所有处理脚本以使用不同的网络路径样式.

额外问题:这同样适用于Linux主机:他们是否足够聪明,知道他们是从本地磁盘中提取的?

Cod*_*ter 5

当我使用这样的映射时,我是否存在产生大量开销的风险,

是.通过使用UNC路径(\\hostname\sharename\filename)而不是本地路径([\\?\]driveletter:\directoryname\filename),您可以通过服务器消息块协议(SMB/Samba)发出所有流量.这通常会增加磁盘访问和访问时间方面的显着开销.

通过网络流动是这样的:

Application -> SMB Client -> Network -> SMB Server -> Target file system
Run Code Online (Sandbox Code Playgroud)

现在通过将文件移动到本地计算机,但仍使用UNC访问它们,流程如下:

Application -> SMB Client -> localhost -> SMB Server -> Target file system
Run Code Online (Sandbox Code Playgroud)

您最小化(未消除,到localhost的SMB流量仍涉及网络层以及所有计算和流量关联)的唯一因素是网络流量.

此外,鉴于SMB专门针对网络流量而定制,其读取可能无法最佳地使用磁盘和操作系统的缓存.例如,它可以在一定大小的块中执行读取,而在读取另一个大小的块时,磁盘的性能会更好.

如果您希望获得最佳吞吐量和最短访问时间,请尽可能使用介于两者之间的小层,在这种情况下,直接访问文件系统:

Application -> Target file system
Run Code Online (Sandbox Code Playgroud)