在使用 JMeter 压测时，发现同一后端服务，在单机 500 并发下，HTTP 和 HTTPS 协议压测 RT 差距非常大。同时观测后端服务各监控指标水位都很低，因此怀疑性能瓶颈在 JMeter 施压客户端。 二、问题分析
切入点：垃圾回收
首先在施压机观察到 CPU 使用率和内存使用率都很高，详细看下各线程 CPU、内存使用情况：
top -Hp {pid}
再看下 gc 的频率和耗时，发现每秒都有 YoungGC，且累计耗时比较长，因此先从频繁 GC 入手，定位问题。
java/bin/jstat -gcutil {pid} 1000
在压测过程中，对 JMeter 的运行进程做了 HeapDump 后，分析下堆内存：
可以看到 cacheMap 对象占用了 93.3%的内存，而它又被 SSLSessionContextImpl 类引用，分析下源码，可以看出，每个 SSLSessionContextImpl 对象构造时，都会初始化 sessionHostPortCache 和 sessionCache 两个软引用 Cache。因为是软引用，所以在内存不足时 JVM 才会回收此类对象。
// 默认缓存大小private final staticint DEFAULT_MAX_CACHE_SIZE = 20480;// package privateSSLSessionContextImpl() {cacheLimit = getDefaultCacheLimit(); // default cache size，这里默认是20480timeout = 86400; // default, 24 hours// use soft reference// 这里初始化了2个默认大小20480的缓存，是频繁GC的原因sessionCache = Cache.newSoftMemoryCache(cacheLimit, timeout);sessionHostPortCache = Cache.newSoftMemoryCache(cacheLimit, timeout);}// 获取默认缓存大小privatestaticintgetDefaultCacheLimit() {try {int defaultCacheLimit = GetIntegerAction.privilegedGetProperty("javax.net.ssl.sessionCacheSize", DEFAULT_MAX_CACHE_SIZE);if (defaultCacheLimit >= 0) {return defaultCacheLimit;} elseif (SSLLogger.isOn && SSLLogger.isOn("ssl")) {SSLLogger.warning("invalid System Property javax.net.ssl.sessionCacheSize, " +"use the default session cache size (" +DEFAULT_MAX_CACHE_SIZE + ") instead");}} catch (Exception e) {// unlikely, log it for safeif (SSLLogger.isOn && SSLLogger.isOn("ssl")) {SSLLogger.warning("the System Property javax.net.ssl.sessionCacheSize is " +"not available, use the default value (" +DEFAULT_MAX_CACHE_SIZE + ") instead");}}return DEFAULT_MAX_CACHE_SIZE;}
通过上述代码，发现 sessionCache 和 sessionHostPortCache 缓存默认大小是 DEFAULT_MAX_CACHE_SIZE，也就是 20480。对于我们压测的场景来说，如果每次请求重新建立连接，那么就根本不需要这块缓存。再看下代码逻辑，发现其实可以通过 javax.net.ssl.sessionCacheSize 来设置缓存的大小，在 JMeter 启动时，添加 JVM 参数-Djavax.net.ssl.sessionCacheSize=1，将缓存大小设置为 1，重新压测验证，观察 GC。
可以看出，YGC 明显变少了，从 1 秒 1 次，变成了 5-6 秒 1 次。那么观察下压测的 RT，结果。。。竟然还是 1800ms，本来 100ms 的服务被压成 1800ms，看来问题不在于 SSLSession 的缓存。再回到 GC 的耗时分析部分，仔细看下，其实 Full GC 只有 1 次，阻塞性的耗时并不多，Young GC 虽然频繁，但阻塞时间很短，也不至于将 SSL 加解密的 CPU 计算时间片全部抢占。看起来压力就是单纯的 SSL 握手次数多，造成了性能瓶颈。
调整思路：为什么频繁 SSL 握手
回到问题背景，我们是在做压力测试，单机会跑很高的并发模拟用户量，出于性能考虑，完全可以一次握手后共享 SSL 连接，后续不再握手，为什么 JMeter 会如此频繁握手呢？
带着这个问题，看了下 JMeter 官方文档，果然有惊喜！
原来 JMeter 有 2 个开关在控制是否重置 SSL 上下文的选项，首先是 https.sessioncontext.shared 控制是否全局共享同一个 SSLContext，如果设为 true，则各线程共享同一个 SSL 上下文，这样对施压机性能压力最低，但不能模拟真实多用户 SSL 握手的情况。
第二个开关 httpclient.reset_state_on_thread_group_iteration 是线程组每次循环是否重置 SSL 上下文，5.0 之后默认为true，也就是说每次循环都会重置 SSL 上下文，看来这就是导致 SSL 频繁握手的原因。
三、问题验证回归测试
在 jmeter.properties 中将配置每个线程循环时，不重置 SSL 上下文，在 PTS 控制台再次启动压测，RT 直接下降 10 倍。
httpclient.reset_state_on_thread_group_iteration=false
修改前
修改后
源码验证
下面从源码层面分析下 JMeter 是怎么实现循环重置 SSL 上下文的，代码如下：
/*** Whether SSL State/Context should be reset* Shared state for any HC based implementation, because SSL contexts are the same */protectedstatic final ThreadLocal<Boolean> resetStateOnThreadGroupIteration =ThreadLocal.withInitial(() -> Boolean.FALSE);/*** Reset SSL State. <br/>* In order to do that we need to:* <ul>* <li>Call resetContext() on SSLManager</li>* <li>Close current Idle or Expired connections that hold SSL State</li>* <li>Remove HttpClientContext.USER_TOKEN from {@link HttpClientContext}</li>* </ul>* @param jMeterVariables {@link JMeterVariables}* @param clientContext {@link HttpClientContext}* @param mapHttpClientPerHttpClientKey Map of {@link Pair} holding {@link CloseableHttpClient} and {@link PoolingHttpClientConnectionManager}*/privatevoidresetStateIfNeeded(JMeterVariables jMeterVariables, HttpClientContext clientContext,Map<HttpClientKey, Pair<CloseableHttpClient, PoolingHttpClientConnectionManager>> mapHttpClientPerHttpClientKey) {if (resetStateOnThreadGroupIteration.get()) {// 关闭当前线程对应连接池的超时、空闲连接，重置连接池状态closeCurrentConnections(mapHttpClientPerHttpClientKey);// 移除TokenclientContext.removeAttribute(HttpClientContext.USER_TOKEN);// 重置SSL上下文((JsseSSLManager) SSLManager.getInstance()).resetContext();// 标记置为false，保证一次循环中，只有第一个采样器走进此逻辑resetStateOnThreadGroupIteration.set(false);}}@OverrideprotectedvoidnotifyFirstSampleAfterLoopRestart() {log.debug("notifyFirstSampleAfterLoopRestart called "+ "with config(httpclient.reset_state_on_thread_group_iteration={})",RESET_STATE_ON_THREAD_GROUP_ITERATION);resetStateOnThreadGroupIteration.set(RESET_STATE_ON_THREAD_GROUP_ITERATION);}
在每次基于 Apache HTTPClient4 的 HTTP 采样器执行时，都会调用 resetStateIfNeeded 方法，在进入方法时读取 httpclient.reset_state_on_thread_group_iteration 配置，即 resetStateOnThreadGroupIteration。如果是 true，重置当前线程的连接池状态、重置 SSL 上下文，然后再将 resetStateOnThreadGroupIteration 置为 false。
因为 JMeter 的并发是基于线程实现的，resetStateOnThreadGroupIteration 这个开关放在 ThreadLocal 里，在每次循环开始时，会调用 notifyFirstSampleAfterLoopRestart 方法，重置开关，运行一次后，强制把开关置为 false。这保证了每次循环只有第一个采样器进入此逻辑，也就是每次循环只执行一次。四、总结
本次解决了 JMeter5.0 版本以上压测 HTTPS 协议的性能问题，经验总结如下：
1)如果希望施压机发挥最大性能，可以将 https.sessioncontext.shared 设为 true，这样所有线程会共享同一个 SSL 上下文，不会频繁握手，但是不能模拟真实情况下多用户的场景。
2)如果希望模拟多个用户，不停循环执行某一个动作，也就是一个线程组每次循环模拟同一个用户的行为，可以将 httpclient.reset_state_on_thread_group_iteration 设置为 false，这样也可以很大的提高单机压测 HTTPS 的性能。
3)如果希望每个线程组每次循环模拟不同用户，那需要设置 httpclient.reset_state_on_thread_group_iteration=true，此时压测会模拟多用户频繁 SSL 握手，施压机性能最低，从经验来看，单机上限 50 并发左右。这也是 JMeter5.0 版本之后的默认设置。
五、拓展：阿里云 JMeter 压测阿里云PTS压测工具链接：https://help.aliyun.com/product/29260.html原文链接来自：https://www.cnblogs.com/alisystemsoftware/p/16298095.html
阿里云PTS 压测工具支持原生 JMeter 脚本，并且在 HTTPS 的压测中已将 httpclient.reset_state_on_thread_group_iteration 默认设置为 false，极大提高压测 HTTPS 时施压机性能，节省压测成本。如果模拟最真实的用户访问情况来压测，可以通过修改 JMeter 环境中的自定义 properties 配置，将 httpclient.reset_state_on_thread_group_iteration 设置为 true。
