windows - 在 go 中提供 samba 文件的矛盾性能

Question

我在 go 中编写了一个程序，它充当 samba 共享的简单 HTTP 接口(interface):用户向 http://proxy.example.com/?path=\\repository\foo\bar.txt 发出 get 请求。和 \\repository\foo\bar.txt通过 http.ServeFile(或多或少)提供。

然而，表现却很糟糕。我运行了一些基准测试，结果让我很难过。对于上下文，图中有三台机器:samba 服务器(文件所在的位置)、代理服务器(go 程序运行的地方)和最终用户的机器(我最终希望文件获取的地方)。 samba 服务器和代理服务器位于同一位置，最终用户相距很远。

使用 Windows 副本从 samba 机器直接复制到用户机器的运行速度约为 1.5MB/s。这对我来说已经足够了，也是我在代理服务中的目标。

不幸的是curl 'http://proxy.example.com/?path=\\repository\foo\bar.txt' > bar.txt来自用户机器的时钟大约为 150KB/s。

那么，让我们看看 samba 服务器和代理服务器之间是否存在连接问题。从 samba 服务器到代理服务器的副本看起来正在……大约 15MB/s。

嗯，也许这是一件好事？我将编写一个 go 程序来衡量传输速度。

src, _ := os.Open("\\\\repository\\foo\\bar.txt")
start := time.Now()
written, _ := io.Copy(ioutil.Discard, src)
elapsed := time.Since(start)
bytesPerSecond := written/int64(elapsed/time.Second)

党，15MB/s。

好吧，好吧，也许 go 代码中还有其他东西导致了这个问题。远程到代理服务器，启动IE，进入 http://proxy.example.com/?path=\\repository\foo\bar.txt , 15MB/秒。

好的，所以我的代码显然运行良好，它必须是代理服务器和最终用户之间的连接。我来复制 bar.txt到代理服务器并在 url 中使用其本地路径， \mycoolfiles\bar.txt .呵呵，1.5MB/s。

为了让事情变得更奇怪，我碰巧有 C:\mycoolfiles设置为名为 \\alexscoolfiles 的网络共享, 和 http://proxy.example.com/?path=\\alexscoolfiles\bar.txt时钟在，dun dun dun，150KB/s。

为了证实这个疯狂，我将 go 程序改为分两步运行:

将文件从共享复制到本地硬盘

http.SendFile 从那里

瞧，在文件以 15MB/s 的速度传输时稍作停顿后，下载以稳定的 1.5MB/s 开始。

所以，share->proxy 是 15MB/s，proxy->user 是 1.5MB/s，但是 share->proxy->user 是……150KB/s？比应该的慢十倍？除非你和代理在同一台机器上，否则它应该和它应该一样快？更进一步，即使访问的是完全相同的文件，只要一个是 UNC 路径而另一个只是本地路径，这个问题就存在吗？

什么？

请帮忙，我只是不知道。

编辑:所以我的预感是(正如评论的那样)它与 TCP 有关。有问题的代码已被隔离到几乎只有 io.Copy。

我知道当读取器是 samba 文件，而写入器是 ioutil.Discard 时，我会获得最大吞吐量。

我知道当读取器是本地文件而写入器是 http.Response 时，无论使用响应的客户端的带宽和 RRT 是多少，我都会获得最大吞吐量。

我知道当读取器是一个 samba 文件时，写入器是一个 http.Response，并且连接是本地的，我得到了最大的吞吐量。

我知道当读取器是 samba 文件时，写入器是 http.Response，并且连接不是本地的，我的吞吐量很差(~1/10)。

查看 io.Copy，似乎唯一可能导致问题的是读取 samba 文件和写入响应的时间之间的相互作用；足够快的写入器使读取 samba 文件达到最大吞吐量，足够快的读取器使 http.Response.Write 达到最大吞吐量，但将它们结合起来会使一切变得糟糕。

非常有帮助的是......实际发生了什么，更重要的是，我如何才能让这个问题消失。

Answer 1

在试图准确地追踪我可以在何处以及在什么情况下重现该问题之后，我终于将其归结为一行:如果我注释掉 io.Copy 使用 ReadFrom 的位置(当前 io/io.go，第 358 行)，我将获得最大吞吐量.

检查 ReadFrom 的实现位置( net/http/server.go ，第 381 行):

// ReadFrom is here to optimize copying from an *os.File regular file
// to a *net.TCPConn with sendfile.

我真的没有深入挖掘的意愿，但我猜这叫 net/sendfile_windows.go ，它调用 TransmitFile 系统调用，在它和我们的各种服务器配置之间的某个地方发生了一些不好的事情。

解决方案是从 http.ServeFile 复制并粘贴我需要的东西，然后在将它传递给 io.Copy 之前将 ResponseWriter 转换为 io.Writer(或其他):

type writerOnly struct {
    io.Writer
}

//...
io.Copy(writerOnly{w}, f)
//...