golang:net.Conn 读得很慢？答案

【问题标题】：golang: net.Conn Read very slow?golang:net.Conn 读得很慢？
【发布时间】：2012-12-29 08:31:25
【问题描述】：

我正在使用 net.Listen("tcp", addr) 作为一个小型服务器程序，它接受数据并将其存储在服务器上。在客户端，我有一个 c++ 程序，我只是将 4096000 BYTES 写入套接字（连接到我的服务器程序）客户端的写入在不到一秒的时间内完成。使用连接 net.Conn 的 Read() 函数时，读取速度非常慢。

下面是 Read() for 循环：

  // Handle the reads
  var tbuf [81920]byte

  for {

    n, err := c.rwc.Read(tbuf[0:])

    // Was there an error in reading ?
    if err != nil {
        log.Printf("Could not read packet : %s", err.Error())
        break
    }

    log.Println(n)

}

return

c.rwc 是 net.Conn 类型

以上代码的输出如下：

2012/12/29 13:45:12 16384
2012/12/29 13:45:12 16018
2012/12/29 13:45:12 16384
2012/12/29 13:45:12 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:13 16016
2012/12/29 13:45:13 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:14 16384
2012/12/29 13:45:14 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:15 16016
2012/12/29 13:45:15 16384
2012/12/29 13:45:16 16016
2012/12/29 13:45:16 16384
2012/12/29 13:45:16 16016
2012/12/29 13:45:16 16384
2012/12/29 13:45:16 16016
2012/12/29 13:45:16 16384
2012/12/29 13:45:16 16016
2012/12/29 13:45:16 16384
2012/12/29 13:45:16 16016
2012/12/29 13:45:18 16384
2012/12/29 13:45:18 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:19 16016
2012/12/29 13:45:19 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:20 16384
2012/12/29 13:45:20 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:21 16016
2012/12/29 13:45:21 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:22 16384
2012/12/29 13:45:22 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:23 16384
2012/12/29 13:45:23 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:24 16016
2012/12/29 13:45:24 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:25 16016
2012/12/29 13:45:25 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:26 16384
2012/12/29 13:45:26 16016
2012/12/29 13:45:27 16384
2012/12/29 13:45:27 16016
2012/12/29 13:45:27 16384
2012/12/29 13:45:27 16016
2012/12/29 13:45:27 16384
2012/12/29 13:45:27 16016
2012/12/29 13:45:27 16384
2012/12/29 13:45:27 16016
2012/12/29 13:45:27 16384
2012/12/29 13:45:28 16016
2012/12/29 13:45:28 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:29 16016
2012/12/29 13:45:29 16384
2012/12/29 13:45:30 16016
2012/12/29 13:45:30 16384
2012/12/29 13:45:30 16016
2012/12/29 13:45:30 16384
2012/12/29 13:45:30 16016
2012/12/29 13:45:30 16384
2012/12/29 13:45:30 16016
2012/12/29 13:45:30 16384
2012/12/29 13:45:30 16016
2012/12/29 13:45:31 16384
2012/12/29 13:45:31 16016
2012/12/29 13:45:31 16384
2012/12/29 13:45:31 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:32 16016
2012/12/29 13:45:32 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:33 16016
2012/12/29 13:45:33 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:34 16016
2012/12/29 13:45:34 16384
2012/12/29 13:45:35 16016
2012/12/29 13:45:35 16384
2012/12/29 13:45:35 16016
2012/12/29 13:45:35 16384
2012/12/29 13:45:35 16016
2012/12/29 13:45:35 16384
2012/12/29 13:45:35 16016
2012/12/29 13:45:36 16384
2012/12/29 13:45:36 16016
2012/12/29 13:45:36 16384
2012/12/29 13:45:36 16016
2012/12/29 13:45:37 16384
2012/12/29 13:45:37 16016
2012/12/29 13:45:37 16384
2012/12/29 13:45:37 16016
2012/12/29 13:45:37 16384
2012/12/29 13:45:37 16016
2012/12/29 13:45:37 16384
2012/12/29 13:45:37 16016
2012/12/29 13:45:37 16384
2012/12/29 13:45:37 16016
2012/12/29 13:45:37 4048

如您所见，读取操作需要将近 21-25 秒才能读取 4096000 个字节，由于服务器和客户端在同一台计算机上，因此速度非常慢。读操作错了吗？我无法理解为什么这么慢？

【问题讨论】：

您的阅读正在使用切片。如果你使用c.rwc.Read(tbuf)会发生什么？

标签： go

【解决方案1】：

我把你的例子做成了一个完整的例子，供客户端和服务器使用。在 Linux 上对其进行测试，它会在 20 毫秒左右传输数据，不会出现意外停顿。

如果您在计算机上尝试，您会得到相同的结果吗？如果是这样，那么怀疑您系统的 C++ 部分。如果出现与原始帖子相同的停顿，则怀疑您的设置。

服务器代码

package main

import (
    "io"
    "log"
    "net"
    "time"
)

func handle(c net.Conn) {
    // Handle the reads
    start := time.Now()
    tbuf := make([]byte, 81920)
    totalBytes := 0

    for {
        n, err := c.Read(tbuf)
        totalBytes += n
        // Was there an error in reading ?
        if err != nil {
            if err != io.EOF {
                log.Printf("Read error: %s", err)
            }
            break
        }
        log.Println(n)
    }
    log.Printf("%d bytes read in %s", totalBytes, time.Now().Sub(start))
    c.Close()
}

func main() {
    srv, err := net.Listen("tcp", ":2000")
    if err != nil {
        log.Fatal(err)
    }
    log.Println("Listening on localhost:2000")
    for {
        conn, err := srv.Accept()
        if err != nil {
            log.Fatal(err)
        }
        go handle(conn)
    }
}

客户端代码

package main

import (
    "log"
    "net"
    "time"
)

func handle(c net.Conn) {
    start := time.Now()
    tbuf := make([]byte, 4096)
    totalBytes := 0
    for i := 0; i < 1000; i++ {
        n, err := c.Write(tbuf)
        totalBytes += n
        // Was there an error in writing?
        if err != nil {
            log.Printf("Write error: %s", err)
            break
        }
        log.Println(n)
    }
    log.Printf("%d bytes written in %s", totalBytes, time.Now().Sub(start))
    c.Close()
}

func main() {
    conn, err := net.Dial("tcp", ":2000")
    if err != nil {
        log.Fatal(err)
    }
    log.Println("Sending to localhost:2000")
    handle(conn)
}

【讨论】：

是的，您的示例运行速度很快。实际上，我在这里使用的是 http 包：groups.google.com/d/msg/golang-nuts/TF1Z2BJW3e0/uKNOFNNlOscJ。所以我猜 net/http 包以某种方式降低了读取速度？先生，您知道吗？
我认为net/http 不太可能导致速度变慢，因为它被称为高性能。我建议你根据上面的代码使用net/http 制作一个独立的客户端和服务器，看看你是否可以重现这个错误。如果您可以使用代码链接更新问题。
我做了更多的测试，看起来缓慢是由 SSL 部分引起的 - ListenAndServeTLS()。如果我使用 ListenAndServe，那么我将获得与常规“net”包示例相同的速度。令人惊讶的是，如果我使用 tls.NewListener(srv, config) 作为您提供的代码的补充，我仍然可以获得很好的速度。出于某种原因，net/http ListenAndServeTLS() 会减慢速度。
@user1066991 恕我直言，您应该将 go 用于 http，并在其前面使用 nginx 之类的东西用于 https，nginx 只是更好地处理这种事情，但 Go 一直在改进。