Go 网络库并发吞吐量测试

github.com/Allenxuxu/g…

本文主要测试 gev 网络库和其余三方 Go 网络库以及标准库的吞吐量对比。

测试对象

• gev ：一个轻量、快速的基于 Reactor 模式的非阻塞 TCP 网络库
• eviop ：evio 的优化版本
• evio ：Fast event-loop networking for Go
• gnet ：eviop 的网络模型替换版本
• net 标准库

测试方法

采用陈硕测试 muduo 使用的 ping pong 协议来测试吞吐量。

简单地说，ping pong 协议是客户端和服务器都实现 echo 协议。当 TCP 链接创建时，客户端向服务器发送一些数据，服务器会 echo 回这些数据，而后客户端再 echo 回服务器。这些数据就会像乒乓球同样在客户端和服务器之间来回传送，直到有一方断开链接为止。这是用来测试吞吐量的经常使用办法。

测试的客户端代码： github.com/Allenxuxu/g…

测试脚本：github.com/Allenxuxu/g…

主要作两项测试：

• 单线程单个 work 协程测试，测试并发链接数为 10/100/1000/10000 时的吞吐量
• 4线程4个 work 协程测试，测试并发链接数为 10/100/1000/10000 时的吞吐量

全部测试中，ping pong 消息的大小均为 4096 bytes，客户端始终是4线程运行。

测试结果

总结与思考

不管是单线程，仍是多线程模式下，gev 都比其余网络库吞吐量略高出一些。

evio 由于 epoll 使用一些 bug 和可优化之处，因此在 linux 环境中的吞吐量远不如优化版本 eviop 。

eviop 是我对 evio bug 修复和优化的版本，因此其性能也是比 evio 提高很多。我曾尝试在 eviop 中替换 evio 的网络模型（evio 利用 accpet 的惊群现象工做），可是由于其代码耦合度太高，修改为本过大，最终决定一边完善 eviop（维持网络模型不变）一边本身借鉴muduo 的网络模型从新撸一个新的 -- gev 。

gnet 是研究了 eviop 的代码，继续在其之上替换网络模型的版本。可是网络模型的优点在单线程模式中并无体现出来，吞吐量反而比 eviop 小一些。在多线程模式下，网络模型的优点得以体现。

gev 与其余使用 epoll 构建的基于事件驱动的网络库在逐步的优化中，相信性能都差很少。由于做者目的不一样，网络库不一样的设计，优点点都会不一样。我研究 evio，最终本身撸了 gev ，也是由于想要一个在内存占用低前提下，速度足够快，能负载更多链接的网络库。

若是对 gev 网络库感兴趣，欢迎提意见和 PR 。➡️ github.com/Allenxuxu/g…