JDK16关于TCP和UDP的优化
文章转自belaban.blogspot.com
Double your performance: virtual threads (fibers) and JDK 15/16!
If you use UDP as transport and want to double your performance: read on!
If you use TCP, your performance won't change much. You might still be interested in what more recent JDKs and virtual threads (used to be called 'fibers') will bring to the table.
Virtual threads
Virtual threads are lightweight threads, similar in concept to the old Green Threads, and are managed by the JVM rather than the kernel. Many virtual threads can map to the same OS native (carrier) thread (only one at a time, of course), so we can have millions of virtual threads.
Virtual threads are implemented with continuations, but that's a detail. What's important is that all blocking calls in the JDK (LockSupport.park() etc) have been modified to yield rather than block. This means that we don't waste the precious native carrier thread, but simply go to a non-RUNNING state. When the block is over, the thread is simply marked as RUNNABLE again and the scheduler continues the continuation where it left off.
Main advantages:
Blocking calls don't need to be changed, e.g. into reactive calls
No need for thread pools: simply create a virtual thread
Fewer context switches (reduced/eliminated blocking calls)
We can have lots of virtual threads
It will be a while until virtual threads show up in your JDK, but JGroups has already added support for it: just set use_fibers="true" in the transport. If the JVM supports virtual threads, they will be used, otherwise we fall back to regular native threads.
UDP: networking improvements
While virtual threads bring advantages to JGroups, the other performance increase can be had by trying a more recent JDK.
Starting in JDK 15, the implementation of DatagramSockets and MulticastSockets has been changed to delegate to DatagramChannels and MulticastChannels. In addition, virtual threads are supported.
This increases the performance of UDP which uses DatagramChannels and MulticastChannels.
The combination of networking code improvements and virtual threads leads to astonishing results for UDP, read below.
Performance
I used UPerf for testing on a cluster of 8 (physical) boxes (1 GBit ethernet), with JDKs 11, 16-ea5 and 16-loom+2-14. The former two use native threads, the latter uses virtual threads.
As can be seen in [1], UDP's performance goes from 44'691 on JDK 11 to 81'402 on JDK 16-ea5; that's a whopping 82% increase! Enabling virtual threads increases the performance between 16-ea5 and 16-loom+2-14 to 88'252, that's another 8%!
The performance difference between JDK 11 and 16-loom is 97%!
The difference in TCP's performance is miniscule; I guess because the TCP code was already optimized in JDK 11.
Running in JDK 16-loom+2-14 shows that UDP's performance is now on par with TCP, as a matter of fact, UDP is even 3% faster than TCP!
If you want to try for yourself: head over to the JGroups Github repo and create the JAR (ant jar). Or wait a bit: I will soon release 5.0.0.Final which contains the changes.
Not sure if I want to backport the changes to the 4.x branch...
Enjoy!
[1] https://drive.google.com/file/d/1Ars1LOM7cEf6AWpPwZHeIfu_kKLa9gv0/view?usp=sharing
[2] http://openjdk.java.net/jeps/373
性能加倍:虚拟线程(光纤)和JDK15/16!
如果您使用UDP作为传输,并希望将性能提高一倍:请继续阅读!
如果使用TCP,性能不会有太大变化。您可能仍然对最近的jdk和虚拟线程(以前称为“fibers”)将带来什么感兴趣。
虚拟线程
虚拟线程是轻量级线程,在概念上类似于旧的绿色线程,由JVM而不是内核来管理。许多虚拟线程可以映射到同一个操作系统本机(运营商)线程(当然,一次只能映射一个),因此我们可以拥有数百万个虚拟线程。
虚拟线程是用continuations实现的,但这只是一个细节。重要的是JDK中的所有阻塞调用(停车场锁支架()等)已修改为屈服而不是阻塞。这意味着我们不会浪费宝贵的本机载波线程,而只是进入非运行状态。当块结束时,线程被简单地再次标记为可运行,调度程序在它停止的地方继续继续执行。
主要优点:
阻塞呼叫不需要更改,例如变为被动呼叫
不需要线程池:只需创建一个虚拟线程
更少的上下文切换(减少/消除阻塞调用)
我们可以有很多虚拟线程
虚拟线程在JDK中出现还需要一段时间,但JGroups已经添加了对它的支持:只需在传输中设置use_fibers=“true”。如果JVM支持虚拟线程,那么将使用它们,否则我们将返回到常规的本机线程。
UDP:网络改进
虽然虚拟线程为jgroup带来了优势,但通过尝试更新的JDK,可以获得其他性能提升。
从jdk15开始,DatagramSockets和MulticastSockets的实现已经改为委托给DatagramChannels和multicast channels。此外,还支持虚拟线程。
这提高了UDP使用DatagramChannels和multicast channels的性能。
网络代码改进和虚拟线程的结合为UDP带来了惊人的结果,如下所示。
性能
用于以太网测试(1-16个)和1-5个虚拟机的JDEAK(16个)和1个。前两个使用本机线程,后一个使用虚拟线程。
从[1]中可以看出,UDP的性能从jdk11上的44'691提高到jdk16-ea5上的81'402;这是惊人的82%的增长!启用虚拟线程可以将16-ea5和16织机+2-14之间的性能提高到88'252,这又是8%!
jdk11和16织机的性能差异是97%!
TCP的性能差别很小;我想是因为TCP代码已经在jdk11中进行了优化。
在jdk16loom+2-14上运行表明UDP的性能已经与TCP不相上下,事实上UDP甚至比TCP快3%!
如果您想自己尝试一下:转到JGroups Github repo并创建JAR(antjar)。或者稍等一下:我很快就会发布5.0.0.Final,其中包含了这些更改。
不确定是否要将更改后传到4.x分支。。。
享受吧!
[1]https://drive.google.com/file/d/1Ars1LOM7cEf6AWpPwZHeIfu kKLa9gv0/view?usp=分享
[2]http://openjdk.java.net/jeps/373
JDK16关于TCP和UDP的优化的更多相关文章
- [转帖]关于网络编程中MTU、TCP、UDP优化配置的一些总结
关于网络编程中MTU.TCP.UDP优化配置的一些总结 https://www.cnblogs.com/maowang1991/archive/2013/04/15/3022955.html 感谢原作 ...
- 【转】关于TCP和UDP协议消息保护边界的介绍
在 socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的 socket,因此,发送端为了将多个发往接收端的包, ...
- TCP和UDP的保护消息边界机制
在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.TCP的socket编程,收发两端都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化 ...
- [译]再次对比TCP与UDP
免责声明:和往常一样,此文章的观点都属于‘No Bugs’Hare(译注:一个网站) ,也许不一定和翻译者或者Overload编辑的意见一致.同时,翻译者从Lapine翻译到英语也具有一定的难度.除此 ...
- 有关TCP和UDP 粘包 消息保护边界
http://www.cnblogs.com/lancidie/archive/2013/10/28/3392428.html 在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因 ...
- TCP和UDP的"保护消息边界" (经典)
在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有 ...
- TCP和UDP的"保护消息边界”
转自:http://blog.csdn.net/zhangxinrun/article/details/6721427 在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP ...
- lvs+keepalive实现主从效果,以及RS健康监测和tcp,udp实现非web的负载均衡
前面文章讲到了tcp和udp负载均衡,但是没有健康监测,这几天我优化了一下上次的操作.当然,我也是用的跨网段的通讯,因为线上业务主要是海外业务,所以做了iptables流量转发 IP: lvs-mas ...
- TCP、UDP详解与抓包工具使用
参考:https://www.cnblogs.com/HPAHPA/p/7737641.html TCP.UDP详解 1.传输层存在的必要性 由于网络层的分组传输是不可靠的,无法了解数据到达终点的时间 ...
随机推荐
- JAVA 连接 ZooKeeper之初体验
Java连接Zookeeper 一.配置zk环境 本人使用的是虚拟机,创建了两台linux服务器(安装过程百度上很多) 准备zk的安装包,zookeeper-3.4.10.tar.gz,可在Apach ...
- 每日一道 LeetCode (6):有效的括号
每天 3 分钟,走上算法的逆袭之路. 前文合集 每日一道 LeetCode 前文合集 代码仓库 GitHub: https://github.com/meteor1993/LeetCode Gitee ...
- 【Python 实例】面向对象 | 按逗号分割列表
[Python 实例]面向对象 | 按逗号分割列表 题目: 按逗号分割列表 应该得到如下结果: ["xx"],["xx"],["xx"] 解 ...
- python2.1 if-else条件语句:
#案例:存款大于100万,买宝马:小于20万自行车! cunkuan=10#if判断条件,else:不满足if执行其他命令if cunkuan>100: print("可以买宝马,好开 ...
- MySQL--->存储引擎及图形化工具
本章目标: 掌握MySQL存储引擎的特点 掌握Navicat图形化工具的使用 了解其他的一些图形化管理工具 1.存储引擎种类: 2. 表级锁和行级锁: 3.常见的引擎: InnoDB 存储引擎 MyI ...
- 前端面试 vue 部分 (3)——v-show和v-if的区别
v-if 适用于在运行时很少改变条件,不需要频繁切换条件的场景: v-show 则适用于需要非常频繁切换条件的场景. v-if 是条件渲染,如果在初始渲染时条件为假,则什么也不做--直到条件第一次变为 ...
- Java连接Redis,存储对象获取对象()byte和json),连接池
Java连接Redis Jedis连接Redis,Lettuce连接Redis Jedis连接Redis 1. 创建maven项目 2. 引入依赖 <dependencies> <d ...
- C#LeetCode刷题之#695-岛屿的最大面积( Max Area of Island)
问题 该文章的最新版本已迁移至个人博客[比特飞],单击链接 https://www.byteflying.com/archives/3736 访问. 给定一个包含了一些 0 和 1的非空二维数组 gr ...
- Vue $nextTick的一个使用场景
$nextTick 官方解释 在下次 DOM 更新循环结束之后执行延迟回调.在修改数据之后立即使用这个方法,获取更新后的 DOM 使用场景 在页面上有2个表单元素和2个按钮 btnRequiredFi ...
- golang 复数
目录 1.声明/赋值/初始化 2.类型 3.取虚实部数值 4.运算 5.注意 跳转 1.声明/赋值/初始化 var name complex128 =complex(x,v) name := comp ...