V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
xuxu555
V2EX  ›  Go 编程语言

Go 网络库并发吞吐量测试

  •  
  •   xuxu555 ·
    Allenxuxu · 2019-09-22 18:13:24 +08:00 · 6102 次点击
    这是一个创建于 1649 天前的主题,其中的信息可能已经有所发展或是发生改变。

    https://github.com/Allenxuxu/gev

    本文主要测试 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 回服务器。这些数据就会像乒乓球一样在客户端和服务器之间来回传送,直到有一方断开连接为止。这是用来测试吞吐量的常用办法。

    测试的客户端代码: https://github.com/Allenxuxu/gev/blob/master/benchmarks/client/main.go

    测试脚本: https://github.com/Allenxuxu/gev/blob/master/benchmarks/bench-pingpong.sh

    主要做两项测试:

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

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

    测试结果

    gev11.png

    gev44.png

    总结与思考

    无论是单线程,还是多线程模式下,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。➡️ https://github.com/Allenxuxu/gev

    16 条回复    2019-09-23 13:29:33 +08:00
    bestkayle
        1
    bestkayle  
       2019-09-22 20:46:23 +08:00 via iPhone
    学习学习,正好需要,嘿嘿
    iPhoneXI
        2
    iPhoneXI  
       2019-09-22 21:02:15 +08:00 via Android   ❤️ 2
    加一下英文文档,发到 hackernews/medium/reddit 上,传播效果应该更好
    reus
        3
    reus  
       2019-09-22 21:02:41 +08:00   ❤️ 1
    https://godoc.org/io#Reader

    你处理 io.Reader.Read 的返回有问题,即使返回的 error 非 nil,返回的 int 也可能大于 0,要先处理大于零的情况,再检查错误
    BBCCBB
        4
    BBCCBB  
       2019-09-22 21:10:12 +08:00
    Go 开放 poll 接口了吗??
    cabing
        5
    cabing  
       2019-09-22 21:14:51 +08:00
    必须 star。

    写个开源的库好难的。特别是对于 996 的程序员们。。
    bxtx999
        6
    bxtx999  
       2019-09-22 21:14:54 +08:00
    很赞,收藏研究下!
    reus
        7
    reus  
       2019-09-22 21:17:43 +08:00
    @BBCCBB epoll 之类是系统调用,直接用就行,没什么开放不开放的说法,从来都不阻止你用: https://godoc.org/syscall#EpollCreate
    xuxu555
        8
    xuxu555  
    OP
       2019-09-22 21:36:35 +08:00
    @reus 非常感谢🙏提醒,我看下
    xuxu555
        9
    xuxu555  
    OP
       2019-09-22 21:37:19 +08:00
    @BBCCBB 系统调用操作 epoll, 一直都有的
    xuxu555
        10
    xuxu555  
    OP
       2019-09-22 21:38:19 +08:00
    @cabing 哈哈,看来同是 996 沦落人啊
    xuxu555
        11
    xuxu555  
    OP
       2019-09-22 21:40:09 +08:00
    @iPhoneXI 非常感谢支持和提醒!!
    Foreverdxa
        12
    Foreverdxa  
       2019-09-22 22:21:34 +08:00
    star =我完全了解了...(_)
    xuxu555
        13
    xuxu555  
    OP
       2019-09-22 22:52:32 +08:00
    @Foreverdxa 不不不,star 就是学会 ,fork 就是我要你! [手动坏笑]
    firefox12
        14
    firefox12  
       2019-09-23 08:05:23 +08:00
    回退到 c++ 时代的设计思想了,性能是好了,但是心智负担加重了,go 的优势没有了。 不知道复杂的业务场景处理起来会怎么样。比如创建 50 万个连接,代码编写会变成怎么样。
    wolfish
        15
    wolfish  
       2019-09-23 09:08:58 +08:00 via Android
    先 star,正好后面研究
    guonaihong
        16
    guonaihong  
       2019-09-23 13:29:33 +08:00
    可有和 http 1.1 和 http 2.0 对比 benchmark ?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3314 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 13:20 · PVG 21:20 · LAX 06:20 · JFK 09:20
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.