为什么 Go 的套接字性能不如 C++ 的套接字？

从现在开始，我们要努力学习啦！今天我给大家带来《为什么 Go 的套接字性能不如 C++ 的套接字？》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

我在 go 和 c++ 中对一个简单的套接字乒乓测试进行了基准测试。客户端首先向服务器发送 0。服务器递增它获得的任何数字并将其发送回客户端。客户端将数字回显给服务器，并在数字达到 1,000,000 时停止。

客户端和服务器都在同一台计算机上，因此我在这两种情况下都使用 unix 套接字。 （我还尝试了同主机 tcp 套接字，显示了类似的结果）。

go 测试需要 14 秒，而 c++ 测试需要 8 秒。这让我感到惊讶，因为我已经运行了相当多的 go 与 c++ 基准测试，并且只要我不触发垃圾收集器，通常 go 的性能与 c++ 一样。

我使用的是 mac，尽管评论者也报告 go 版本在 linux 上速度较慢。

想知道我是否缺少优化 go 程序的方法，或者是否只是底层效率低下。

以下是我执行测试时运行的命令以及测试结果。所有代码文件都粘贴在该问题的底部。

运行go服务器：

$ rm /tmp/go.sock
$ go run socketunixserver.go

运行go客户端：

$ go build socketunixclient.go; time ./socketunixclient

real    0m14.101s
user    0m5.242s
sys     0m7.883s

运行 c++ 服务器：

$ rm /tmp/cpp.sock
$ clang++ -std=c++11 tcpserverincunix.cpp -o3; ./a.out

运行 c++ 客户端：

$ clang++ -std=c++11 tcpclientincunix.cpp -o3; time ./a.out

real    0m8.690s
user    0m0.835s
sys     0m3.800s

代码文件

转到服务器：

// socketunixserver.go

package main

import (
    "log"
    "net"
    "encoding/binary"
)

func main() {
    ln, err := net.listen("unix", "/tmp/go.sock")
    if err != nil {
        log.fatal("listen error: ", err)
    }

    c, err := ln.accept()
    if err != nil {
        panic(err)
    }
    log.println("connected with client!")

    readbuf := make([]byte, 4)
    writebuf := make([]byte, 4)
    for {
        c.read(readbuf)
        clientnum := binary.bigendian.uint32(readbuf)
        binary.bigendian.putuint32(writebuf, clientnum+1)

        c.write(writebuf)
    }
}

go 客户端：

// socketunixclient.go

package main

import (
    "log"
    "net"
    "encoding/binary"
)

const n = 1000000

func main() {
    c, err := net.dial("unix", "/tmp/go.sock")
    if err != nil {
        log.fatal("dial error", err)
    }
    defer c.close()

    readbuf := make([]byte, 4)
    writebuf := make([]byte, 4)

    var currnumber uint32 = 0
    for currnumber < n {
        binary.bigendian.putuint32(writebuf, currnumber)
        c.write(writebuf)

        // read the incremented number from server
        c.read(readbuf[:])
        currnumber = binary.bigendian.uint32(readbuf)
    }
}

c++ 服务器：

// tcpserverincunix.cpp

// server side c/c++ program to demonstrate socket programming
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/un.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <unistd.h>

// big endian (network order)
unsigned int frombytes(unsigned char b[4]) {
    return b[3] | b[2]<<8 | b[1]<<16 | b[0]<<24;
}

void tobytes(unsigned int x, unsigned char (&b)[4]) {
    b[3] = x;
    b[2] = x>>8;
    b[1] = x>>16;
    b[0] = x>>24;
}

int main(int argc, char const *argv[])
{
    int server_fd, new_socket, valread;
    struct sockaddr_un saddr;
    int saddrlen = sizeof(saddr);
    unsigned char recv_buffer[4] = {0};
    unsigned char send_buffer[4] = {0};

    server_fd = socket(af_unix, sock_stream, 0);

    saddr.sun_family = af_unix;
    strncpy(saddr.sun_path, "/tmp/cpp.sock", sizeof(saddr.sun_path));
    saddr.sun_path[sizeof(saddr.sun_path)-1] = '\0';
    bind(server_fd, (struct sockaddr *)&saddr, sizeof(saddr));

    listen(server_fd, 3);

    // accept one client connection
    new_socket = accept(server_fd, (struct sockaddr *)&saddr, (socklen_t*)&saddrlen);
    printf("connected with client!\n");

    // note: if /tmp/cpp.sock already exists, you'll get the connected with client!
    // message before running the client. delete this file first.

    unsigned int x = 0;

    while (true) {
        valread = read(new_socket, recv_buffer, 4);
        x = frombytes(recv_buffer);
        tobytes(x+1, send_buffer);

        write(new_socket, send_buffer, 4);
    }
}

c++ 客户端：

// tcpClientIncUnix.cpp

// Server side C/C++ program to demonstrate Socket programming
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <unistd.h>

// Big Endian (network order)
unsigned int fromBytes(unsigned char b[4]) {
    return b[3] | b[2]<<8 | b[1]<<16 | b[0]<<24;
}

void toBytes(unsigned int x, unsigned char (&b)[4]) {
    b[3] = x;
    b[2] = x>>8;
    b[1] = x>>16;
    b[0] = x>>24;
}

int main(int argc, char const *argv[])
{
    int sock, valread;
    struct sockaddr_un saddr;
    int opt = 1;
    int saddrlen = sizeof(saddr);

    // We'll be passing uint32's back and forth
    unsigned char recv_buffer[4] = {0};
    unsigned char send_buffer[4] = {0};

    sock = socket(AF_UNIX, SOCK_STREAM, 0);

    saddr.sun_family = AF_UNIX;
    strncpy(saddr.sun_path, "/tmp/cpp.sock", sizeof(saddr.sun_path));
    saddr.sun_path[sizeof(saddr.sun_path)-1] = '\0';

    // Accept one client connection
    if (connect(sock, (struct sockaddr *)&saddr, sizeof(saddr)) != 0) {
        throw("connect failed");
    }

    int n = 1000000;

    unsigned int currNumber = 0;
    while (currNumber < n) {
        toBytes(currNumber, send_buffer);
        write(sock, send_buffer, 4);

        // Read the incremented number from server
        valread = read(sock, recv_buffer, 4);
        currNumber = fromBytes(recv_buffer);
    }
}

解决方案

首先，我确认这个问题中的 go 程序的运行速度确实比 c++ 程序慢得多。我认为了解其中的原因确实很有趣。

我使用 pprof 分析了 go 客户端和服务器，发现 syscall.syscall 占用了总执行时间的 70%。根据 this 票证，go 中的系统调用比 c 中大约慢 1.4 倍。

(pprof) top -cum
Showing nodes accounting for 18.78s, 67.97% of 27.63s total
Dropped 44 nodes (cum <= 0.14s)
Showing top 10 nodes out of 44
  flat  flat%   sum%        cum   cum%
 0.11s   0.4%   0.4%     22.65s 81.98%  main.main
     0     0%   0.4%     22.65s 81.98%  runtime.main
18.14s 65.65% 66.05%     19.91s 72.06%  syscall.Syscall
 0.03s  0.11% 66.16%     12.91s 46.72%  net.(*conn).Read
 0.10s  0.36% 66.52%     12.88s 46.62%  net.(*netFD).Read
 0.16s  0.58% 67.10%     12.78s 46.25%  internal/poll.(*FD).Read
 0.06s  0.22% 67.32%     11.87s 42.96%  syscall.Read
 0.11s   0.4% 67.72%     11.81s 42.74%  syscall.read
 0.02s 0.072% 67.79%      9.30s 33.66%  net.(*conn).Write
 0.05s  0.18% 67.97%      9.28s 33.59%  net.(*netFD).Write

我逐渐减少了 conn.write 和 conn.read 调用的数量，并相应地增加了缓冲区的大小，以便传输的字节数保持不变。结果是程序进行的调用越少，其性能就越接近 c++ 版本。

终于介绍完啦！小伙伴们，这篇关于《为什么 Go 的套接字性能不如 C++ 的套接字？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！