记一次 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的原因
        sessionCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
        sessionHostPortCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
    }

    // 获取默认缓存大小
    private static int getDefaultCacheLimit() {
        try {
            int defau