目录
前言:
在进行性能测试时,JMeter是一个常用的工具,可以模拟大量并发用户来测试系统的负载和性能。然而,当我们在使用JMeter进行HTTPS性能测试时,可能会遇到一些性能问题。
问题背景
在使用 JMeter 压测时,发现同一后端服务,在单机 500 并发下,HTTP 和 HTTPS 协议压测 RT 差距非常大。同时观测后端服务各监控指标水位都很低,因此怀疑性能瓶颈在 JMeter 施压客户端。
问题分析
切入点:垃圾回收
首先在施压机观察到 CPU 使用率和内存使用率都很高,详细看下各线程 CPU、内存使用情况:
top -Hp {pid}
发现进程的 CPU 使用率将近打满,其中 GC 线程 CPU 使用率很高
再看下 gc 的频率和耗时,发现每秒都有 YoungGC,且累计耗时比较长,因此先从频繁 GC 入手,定位问题。
java/bin/jstat -gcutil {pid} 1000
在压测过程中,对 JMeter 的运行进程做了 HeapDump 后,分析下堆内存:
可以看到 cacheMap 对象占用了 93.3%的内存,而它又被 SSLSessionContextImpl 类引用,分析下源码,可以看出,每个 SSLSessionContextImpl 对象构造时,都会初始化 sessionHostPortCache 和 sessionCache 两个软引用 Cache。因为是软引用,所以在内存不足时 JVM 才会回收此类对象。
// 默认缓存大小
private final static int DEFAULT_MAX_CACHE_SIZE = 20480;
// package private
SSLSessionContextImpl() {
cacheLimit = getDefaultCacheLimit(); // default cache size,这里默认是20480
timeout = 86400; // default, 24 hours
// use soft reference
// 这里初始化了2个默认大小20480的缓存,是频繁GC的原因
sessio