V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yazinnnn
V2EX  ›  程序员

virtual thread 在 jdk21+graalvm 条件下简单测试

  •  
  •   yazinnnn · 220 天前 · 2837 次点击
    这是一个创建于 220 天前的主题,其中的信息可能已经有所发展或是发生改变。
    测试框架是 quarkus(resteasy reactive) 3.3.3
    cpu i5 10400
    jdk 版本



    api 响应内容



    测试代码(直接返回字符串与模拟进行 100 毫秒业务后返回字符串)

    https://gist.github.com/yazinnnn/92a90ddb81579fdc619ca14395bf3dc2

    测试命令(wrk 10 线程 5000 连接 5 秒)

    wrk -t 10 -c 5000 -d 5s ~


    首尾的 rss 分别为启动时和测试后的内存占用
    native 结果(堆内存 200m)



    jvm 结果(堆内存 200m)



    两者的应用大小及启动时间对比

    22 条回复    2023-09-21 11:43:11 +08:00
    yazinnnn
        1
    yazinnnn  
    OP
       220 天前
    补充一个 spring webflux 的简单测试(尚未支持 virtual thread)

    native(-Xmx200m)



    jvm(-Xmx200m)



    启动时间

    1055619878
        2
    1055619878  
       220 天前
    有没有省流版本
    taogen
        3
    taogen  
       220 天前
    同求
    leexiaolang
        4
    leexiaolang  
       220 天前
    内存占用降低,启动时间短,但是性能下降了?
    mmdsun
        5
    mmdsun  
       220 天前
    spring boot 是不是要配置虚拟线程,默认是普通线程池?
    Akitora
        6
    Akitora  
       220 天前
    看起来在 quarkus 和 webflux 下,测试结束时 native 内存占用是 jvm 的一半左右,但同时吞吐量也下降了是比较意外的,这样的话 native 最大的优势只是启动速度吗……

    以及比较好奇的是 native 会不会在 gc 后把内存还给操作系统?
    zhady009
        7
    zhady009  
       220 天前
    @Akitora 没有给出 build args ,没指定的话默认是 Serial GC 要加上--gc=g1 看看是不是因为 gc 的原因
    ixiaohei
        8
    ixiaohei  
       220 天前
    @zhady009 jdk21 serial gc 还没删掉么?
    zhady009
        9
    zhady009  
       220 天前
    @ixiaohei https://tschatzl.github.io/2023/08/04/jdk21-g1-parallel-gc-changes.html 还在,反正不是构建 native-image 的话默认都不是这个,无所谓
    netabare
        10
    netabare  
       220 天前 via Android   ❤️ 1
    看了一下 quarkus 的 blog ,感觉对这个其实没啥太大的兴趣。reactive 的技术栈下,「开很多个线程」并不是一个痛点。

    就是不知道 virtual thread 对 reactive 技术栈有没有什么帮助了。感觉还是存疑。
    salmon5
        11
    salmon5  
       220 天前
    @ixiaohei JDK21 默认还是 G1GC ,SerialGC 、ParallelGC 都还支持,从 JDK9 废弃 JDK14 移除的是 CMS GC ;
    JDK21 新增了分代 ZGC ,但不是默认
    ikas
        12
    ikas  
       220 天前
    virtual thread 本身就是为了代替 reactive ,异步等方式来实现高吞吐 io 的

    目前最大的好处也就是是使用简单的同步方式来编写代码,性能肯定还需要打磨的
    Leviathann
        13
    Leviathann  
       220 天前
    @netabare 可以做 await
    bringyou
        14
    bringyou  
       220 天前
    刚好 spring 也出了一篇文章介绍 Java21 + graalvm
    https://spring.io/blog/2023/09/20/hello-java-21
    cp19890714
        15
    cp19890714  
       220 天前   ❤️ 1
    这个结果很不错了。使用 虚拟线程+同步编程 就可以达到响应式编程 90%的效果,这已经可以降低成本了。
    duduke
        16
    duduke  
       220 天前
    cpu 密集型性能肯定会下降,io 密集型的应该会有帮助,看 op 的结果有这个倾向,应该再上点请求量,可能会比较显著
    kneo
        17
    kneo  
       220 天前 via Android
    结论?
    ymmud
        18
    ymmud  
       220 天前
    加上数据库最好
    hez2010
        19
    hez2010  
       220 天前
    虚拟线程的方式性能是不如 async/await 以及 reactive 的,但好处是解放了双手,不需要大幅度修改代码就能让已有同步阻塞代码的吞吐量得到提升。
    Cabana
        20
    Cabana  
       220 天前
    感觉还是类似 Kotlin 的协程好用些
    xiaocaiji111
        21
    xiaocaiji111  
       219 天前
    极限性能还是要靠线程池+netty 那一套网络模型,基本上 go 也好,rust 也好,网络库最终都走了这套。不过可以大大降低普通人在业务开发中编写高性能程序的难度,已经很不错了。编译成 native 好像非企业版,默认是 serialGC ,真难顶。
    litchinn
        22
    litchinn  
       219 天前
    https://www.bilibili.com/video/BV1Ju4y1Q788
    这个视频我觉得讲的听清楚的

    测试我觉得应该是写个请求,请求其他服务器资源。对比虚拟线程和传统多线程的响应,以及试试虚拟线程的数量级

    虚拟线程和原生镜像,使用前需要慎重考虑当前场景是否适用,感觉他们更像是加入的新功能,而非可以完全替代旧有功能的进化版
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2517 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 15:52 · PVG 23:52 · LAX 08:52 · JFK 11:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.