多个以太网连接对 I/O 密集型任务吞吐量的影响

使用多个以太网连接处理 I/O 密集型任务时，与其预期相反，吞吐量可能会下降。这可能是由于内核流程、Go 例程调度以及syscall时间等因素造成的。当使用两个以太网适配器时，内核层可能会遇到问题，而频繁的Go例程切换也会导致开销。此外，如果syscall时间非线性增加，则表明应用程序外部存在瓶颈，从而限制了吞吐量。通过调整Go例程数量和分析应用程序配置文件，可以确定造成减速的具体原因并进行优化。

所以我遇到了一个有趣的问题，这对我来说似乎违反直觉。我正在构建一个工具，其中最大的瓶颈是发送数据包的速率。目前，我可以在不到 30 秒的时间内处理超过一百万个请求，这很棒，但我正在尝试尽可能提高速度。我的想法是将第二个以太网适配器连接到机器上并启动两个不同的网络。拨号器就像这样

net.dialer{
        timeout:   time.duration(*timeoutptr) * time.second,
        localaddr: addr,
}

其中 addr 是两个以太网适配器之一。然后我将拨号器分配给作业循环方式，如下所示：

for i, target :=  range targets {
    dialer = dialers[i%len(dialers)]
    ....
    go someNetworkFunction(dialer)
}

令我惊讶的是，当我使用 2 个适配器运行它时，它的执行速度要慢得多，30 秒 vs 2 分钟！我只是想理解为什么给代码提供两个连接来发送数据包会减慢代码而不是加快速度。那里的模数运算似乎不会导致 300% 的减速。当尝试使用两个适配器同时发送时，内核层是否发生了某些情况？任何帮助，将不胜感激。

解决方案

可能有多种因素在起作用：

1. 一般的内核或基准测试流程。

如果您运行应用程序的配置文件，该应用程序在 30 秒内发出 mln 请求，并没有花费太多应用程序时间，您可能会发现 syscall 占用了您更多的时间。 syscall 代表应用程序视图之外的（视图之外的）CPU 时间花费。

如果与您正在进行基准测试的进程相比，syscall 时间呈非线性增加，则表明您的程序外部存在瓶颈。

1. Go 例程

go 例程是针对 CPU 核心进行调度的（在物理层面上）。虽然它们很容易创建，但 Go 例程之间的实际切换并不是没有开销的。 someNetworkFunction 的实现可以对吞吐量产生影响，您可能会阻塞资源，或者只是过于频繁地切换。您可以尝试通过使用 GOMAXPROCS 指示 go 程序使用更少的线程来管理此问题。通过调整此值，您可以确定程序和硬件的最佳值。

有关调度程序的更深入说明可以在 https://rakyll.org/scheduler/ 找到

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~