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

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

  •  
  •   yazinnnn · 2023-09-20 10:56:14 +08:00 · 3208 次点击
    这是一个创建于 416 天前的主题,其中的信息可能已经有所发展或是发生改变。
    测试框架是 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
       2023-09-20 11:20:37 +08:00
    补充一个 spring webflux 的简单测试(尚未支持 virtual thread)

    native(-Xmx200m)



    jvm(-Xmx200m)



    启动时间

    1055619878
        2
    1055619878  
       2023-09-20 14:33:48 +08:00
    有没有省流版本
    taogen
        3
    taogen  
       2023-09-20 14:45:06 +08:00
    同求
    leexiaolang
        4
    leexiaolang  
       2023-09-20 15:48:55 +08:00
    内存占用降低,启动时间短,但是性能下降了?
    mmdsun
        5
    mmdsun  
       2023-09-20 16:31:32 +08:00
    spring boot 是不是要配置虚拟线程,默认是普通线程池?
    Akitora
        6
    Akitora  
       2023-09-20 16:41:10 +08:00
    看起来在 quarkus 和 webflux 下,测试结束时 native 内存占用是 jvm 的一半左右,但同时吞吐量也下降了是比较意外的,这样的话 native 最大的优势只是启动速度吗……

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

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

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

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

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