性能测试

JVM GC 性能测试系列: JVM GC 性能对比方法 JVM GC 性能测试（一）：相同流量 JVM GC 性能测试（二）：递增流量 JVM GC 性能测试（三）：真实流量书接上文，在 JVM GC 性能测试（二）：递增流量的最后，D瓜哥提到了一个问题，对于在 JVM GC 性能测试（一）：相同流量和 JVM GC 性能测试（二）：递增流量中存在的巨大 QPS 差异疑惑不解。所以，D瓜哥决定将测试机器接入到线上环境，在真实访问中，观察各个 GC 的表现。一言以蔽之 J21-Gen-ZGC 和 J21-G1 无论在稳定性，吞吐量以及响应时效性上都非常优秀。再极端峰值情况，J21-G1 是更好的选择，更加稳定，不容易出凸点。日常使用，J21-Gen-ZGC 响应性更好，接口耗时更低。鉴于 OpenJDK 21 G1 GC 一如既往的惊艳表现，D瓜哥准备整理一下 G1 GC 的主要优化，敬请关注： Java G1 垃圾收集器主要优化。 1. 服务调用监控数据监控服务调用的相关数据，这是对于用户来说，感知最强烈的相关数据，也是直接关系到服务质量的数据。 1.1. 服务调用次数从调用次数上来看，五个分组没有大的变化，可以说根本没有达到系统的极限峰值。当然，这才是正常现象，如果日常运行都爆峰值，那说明系统早该扩容了。图 1. 服务调用次数（秒级）图 2. 服务调用次数（分钟级） 1.2. 服务调用耗时整体上讲，J21-Gen-ZGC 的耗时更短，从数据上来看，TP999 能比 J21-G1 的少 10~20ms；TP99 更加夸张，J21-Gen-ZGC 的耗时只有 J21-G1 的一半。 J21-Gen-ZGC 和 J21-G1 还是一如既往的稳。这次测试中，J17-ZGC 也很稳，有些出乎意料。但是，结合下面 JVM CPU 使用率和系统 CPU 使用率来看，J17-ZGC 和 J21-ZGC 的 CPU 使用率早早就达到 90%+，再结合上面两个测试，从稳定性来看，J17-ZGC 和 J21-ZGC 只能被排除掉。

JVM GC 性能测试系列: JVM GC 性能对比方法 JVM GC 性能测试（一）：相同流量 JVM GC 性能测试（二）：递增流量 JVM GC 性能测试（三）：真实流量在上一篇文章 JVM GC 性能测试（一）：相同流量中，D瓜哥使用一个总量请求对所有分组的所有机器进行性能测试。但是，经过测试发现了一个问题，同时产生了另外一个问题，有两个问题没有得到很好的解答：由于服务响应时长直接关系到服务调用次数，当某一台机器出现问题时，整体调用次数就会急剧下降，调用次数加不上去。一个机器出问题，所有机器的访问量就上不去了。这是测试中发现的一个问题。当然，这属于测试工具的问题，别不是 GC 的问题。但是，也影响到我们的压测，也需要解决。上次测试，这是针对某一个指定服务调用量进行性能测试，那么，无法确定每个 GC 能支撑的极限调用峰值。另外，在极限峰值和超极限峰值的情况下，各个 GC 的表现如何？这个也有待验证。针对上述两个问题，设计了本次测试。测试方法如下：各个分组使用一套相同的流量策略：各个分组几乎同时开始执行测试任务；调用量从低到高，以此同时使用相关的调用量进行测试；除最开始预热阶段的调用量外，后续每个调用量都持续进行十分钟的测试。针对每个 GC 分组单独设定一套调用发量程序，这个保证各个 GC 分组直接不相互影响。最后，再分析调用量相同时段的各个 GC 表现，就可以看到各个 GC 的极限峰值。为了保留更多细节，本文所有截图都是在 34 吋带鱼屏下，使用全屏模式展示并截图的。如果看不清楚，可以右击在新页面打开图片来查看。具体流量及时间段： 750， 23:14:30 ~ 23:19:30 800， 23:19:30 ~ 23:29:30 850， 23:29:30 ~ 23:39:30 900， 23:39:30 ~ 23:49:30 950， 23:49:30 ~ 23:59:30 1000，23:59:30 ~ 00:09:30 1050，00:09:30 ~ 00:19:30 1100，00:19:30 ~ 00:29:30

JVM GC 性能测试系列: JVM GC 性能对比方法 JVM GC 性能测试（一）：相同流量 JVM GC 性能测试（二）：递增流量 JVM GC 性能测试（三）：真实流量在上一篇文章 JVM GC 性能对比方法介绍了性能对比的方法，这篇文章就根据该方法对上述提到的5种 JVM GC 进行性能测试。在正式测试之前，D瓜哥进行了多次小流量试探性测试，来探索一个合适的量。找到一个比较平稳的量后，乘以机器数量，获得一个每秒总计请求量，最后使用该总量数据去做压测。根据多次测试的数据来看，最后选择的是每台每秒 500 QPS，5 个分组，每个分组 5 台机器，所以，每秒的请求总量是： 500 * 5 * 5 = 12500 QPS；每个分组每分钟的总量是：500 * 5 * 60 = 150000 QPS。使用每台机器以此使用 100 QPS，200 QPS，300 QPS，400 QPS 各运行一分钟来对系统进行预热。最后以每台每秒 500 QPS 的访问量来对测试机器进行持续十分钟的性能测试，最后分析这十分钟的相关数据。一言以蔽之服务稳定性：J21-Gen-ZGC、J21-G1、J8-G1 稳定性最好；J17-ZGC 有轻微波动；J21-ZGC 有剧烈波动；服务耗时 TP999：J21-Gen-ZGC < J17-ZGC < J21-G1 < J8-G1 < J21-ZGC； CPU 消耗：J21-G1 < J8-G1 < J17-ZGC < J21-Gen-ZGC < J21-ZGC；

JVM GC 性能测试系列: JVM GC 性能对比方法 JVM GC 性能测试（一）：相同流量 JVM GC 性能测试（二）：递增流量 JVM GC 性能测试（三）：真实流量现在部门内部绝大部分应用都还在使用 OpenJDK 8，计划推进部门升级 JDK 到 OpenJDK21。本着实事求是，用数据说话的原则，准备对如下 GC 做性能测试： OpenJDK 8 G1 GC（以下称 J8-G1。具体版本号：1.8.0_321-b07。） OpenJDK 17 ZGC（以下称 J17-ZGC。具体版本号：17.0.9+9。） OpenJDK 21 G1（以下称 J21-G1。具体版本号：21.0.2+13-LTS。） OpenJDK 21 ZGC（以下称 J21-ZGC。具体版本号：21.0.2+13-LTS。） OpenJDK 21 Gen ZGC（以下称 J21-Gen-ZGC。具体版本号：21.0.2+13-LTS。）所有 OpenJDK 版本都是选用相同大版本号里的最高的版本。所有的机器都是 4C8G 的配置，JVM 堆栈内存设置为 4608M 。为了减少不必要的干扰，JVM 相关参数也尽可能做到了一致或者接近。（等测试完，D瓜哥会把相关参数也分享出来。）测试对象由于D瓜哥所处的部门是一个直接面向用户的线上业务部门，所以，大部分系统是直接面对用户，接受用户访问的在线业务系统。所以，为了服务线上业务系统的需求，测试对象的选择就限定在了类似的场景中。测试对象是线上接受用户访问的一个服务。结构如下：图 1. 压测接口依赖关系图该接口有外部依赖服务，也有数据库查询，是一个微服务架构下典型的在线服务接口。测试方法原本计划是想直接通过上线，将线上不同分组的机器使用不同的 GC 来做测试，但是，这样面临好几个问题：