这是一个创建于 448 天前的主题，其中的信息可能已经有所发展或是发生改变。
测试框架是 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)
两者的应用大小及启动时间对比
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)
两者的应用大小及启动时间对比
 |
1
yazinnnn OP 补充一个 spring webflux 的简单测试(尚未支持 virtual thread)
native(-Xmx200m)  jvm(-Xmx200m)  启动时间  |
 |
2
1055619878 2023-09-20 14:33:48 +08:00
有没有省流版本
|
 |
3
taogen 2023-09-20 14:45:06 +08:00
同求
|
 |
4
leexiaolang 2023-09-20 15:48:55 +08:00
内存占用降低，启动时间短，但是性能下降了？
|
 |
5
mmdsun 2023-09-20 16:31:32 +08:00
spring boot 是不是要配置虚拟线程，默认是普通线程池？
|
 |
6
Akitora 2023-09-20 16:41:10 +08:00
看起来在 quarkus 和 webflux 下，测试结束时 native 内存占用是 jvm 的一半左右，但同时吞吐量也下降了是比较意外的，这样的话 native 最大的优势只是启动速度吗……
以及比较好奇的是 native 会不会在 gc 后把内存还给操作系统？ |
 |
7
zhady009 2023-09-20 18:04:51 +08:00
@Akitora 没有给出 build args ，没指定的话默认是 Serial GC 要加上--gc=g1 看看是不是因为 gc 的原因
|
|
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 的话默认都不是这个，无所谓
|
 |
10
netabare 2023-09-20 18:59:21 +08:00 via Android  1
看了一下 quarkus 的 blog ，感觉对这个其实没啥太大的兴趣。reactive 的技术栈下，「开很多个线程」并不是一个痛点。
就是不知道 virtual thread 对 reactive 技术栈有没有什么帮助了。感觉还是存疑。 |
 |
11
salmon5 2023-09-20 19:49:47 +08:00
@ixiaohei JDK21 默认还是 G1GC ，SerialGC 、ParallelGC 都还支持，从 JDK9 废弃 JDK14 移除的是 CMS GC ；
JDK21 新增了分代 ZGC ，但不是默认 |
 |
12
ikas 2023-09-20 20:47:27 +08:00
virtual thread 本身就是为了代替 reactive ,异步等方式来实现高吞吐 io 的
目前最大的好处也就是是使用简单的同步方式来编写代码,性能肯定还需要打磨的 |
 |
13
Leviathann 2023-09-20 20:50:33 +08:00
@netabare 可以做 await
|
 |
14
bringyou 2023-09-20 21:02:54 +08:00
刚好 spring 也出了一篇文章介绍 Java21 + graalvm
https://spring.io/blog/2023/09/20/hello-java-21 |
 |
15
cp19890714 2023-09-20 21:03:18 +08:00 1
这个结果很不错了。使用 虚拟线程+同步编程 就可以达到响应式编程 90%的效果，这已经可以降低成本了。
|
 |
16
duduke 2023-09-20 21:26:48 +08:00
cpu 密集型性能肯定会下降，io 密集型的应该会有帮助，看 op 的结果有这个倾向，应该再上点请求量，可能会比较显著
|
 |
17
kneo 2023-09-20 22:38:51 +08:00 via Android
结论？
|
 |
18
ymmud 2023-09-20 22:41:12 +08:00
加上数据库最好
|
 |
19
hez2010 2023-09-20 22:44:59 +08:00
虚拟线程的方式性能是不如 async/await 以及 reactive 的，但好处是解放了双手，不需要大幅度修改代码就能让已有同步阻塞代码的吞吐量得到提升。
|
 |
20
Cabana 2023-09-20 23:04:42 +08:00
感觉还是类似 Kotlin 的协程好用些
|
 |
21
xiaocaiji111 2023-09-21 10:54:42 +08:00
极限性能还是要靠线程池+netty 那一套网络模型，基本上 go 也好，rust 也好，网络库最终都走了这套。不过可以大大降低普通人在业务开发中编写高性能程序的难度，已经很不错了。编译成 native 好像非企业版，默认是 serialGC ，真难顶。
|
 |
22
litchinn 2023-09-21 11:43:11 +08:00
https://www.bilibili.com/video/BV1Ju4y1Q788
这个视频我觉得讲的听清楚的 测试我觉得应该是写个请求，请求其他服务器资源。对比虚拟线程和传统多线程的响应，以及试试虚拟线程的数量级 虚拟线程和原生镜像，使用前需要慎重考虑当前场景是否适用，感觉他们更像是加入的新功能，而非可以完全替代旧有功能的进化版 |
Select Language