问题背景
在使用JMeter压测时，发现同一后端服务，在单机500并发下，HTTP和HTTPS协议压测RT差距非常大。同时观测后端服务各监控指标水位都很低，因此怀疑性能瓶颈在JMeter施压客户端。
问题分析
切入点：垃圾回收
首先在施压机观察到CPU使用率和内存使用率都很高，详细看下各线程CPU、内存使用情况：
top -Hp {pid}发现进程的CPU使用率将近打满，其中GC线程CPU使用率很高
再看下gc的频率和耗时，发现每秒都有YoungGC，且累计耗时比较长，因此先从频繁GC入手，定位问题。
/opt/taobao/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 defaultCacheLimit = GetIntegerAction.privilegedGetProperty(
"javax.net.ssl.sessionCacheSize", DEFAULT_MAX_CACHE_SIZE);
if (defaultCacheLimit >= 0) {
return defaultCacheLimit;
} else if (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 safe
if (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之后默认为false，也就是说每次循环都会重置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
*/
protected static 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}
*/
private void resetStateIfNeeded(JMeterVariables jMeterVariables,
HttpClientContext clientContext,
Map<HttpClientKey, Pair<CloseableHttpClient, PoolingHttpClientConnectionManager>> mapHttpClientPerHttpClientKey) {
if (resetStateOnThreadGroupIteration.get()) {
// 关闭当前线程对应连接池的超时、空闲连接，重置连接池状态
closeCurrentConnections(mapHttpClientPerHttpClientKey);
// 移除Token
clientContext.removeAttribute(HttpClientContext.USER_TOKEN);
// 重置SSL上下文
((JsseSSLManager) SSLManager.getInstance()).resetContext();
// 标记置为false，保证一次循环中，只有第一个采样器走进此逻辑
resetStateOnThreadGroupIteration.set(false);
}
}
@Override
protected void notifyFirstSampleAfterLoopRestart() {
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协议的性能问题，经验总结如下：
-
如果希望施压机发挥最大性能，可以将https.sessioncontext.shared设为true，这样所有线程会共享同一个SSL上下文，不会频繁握手，但是不能模拟真实情况下多用户的场景。
-
如果希望模拟多个用户，不停循环执行某一个动作，也就是一个线程组每次循环模拟同一个用户的行为，可以将httpclient.reset_state_on_thread_group_iteration设置为false，这样也可以很大的提高单机压测HTTPS的性能。
-
如果希望每个线程组每次循环模拟不同用户，那需要设置httpclient.reset_state_on_thread_group_iteration=true，此时压测会模拟多用户频繁SSL握手，施压机性能最低，从经验来看，单机上限50并发左右。这也是JMeter5.0版本之后的默认设置。
云上JMeter压测
阿里云PTS压测工具支持原生JMeter脚本，并且在HTTPS的压测中已将httpclient.reset_state_on_thread_group_iteration默认设置为false，极大提高压测HTTPS时施压机性能，节省压测成本。
如果模拟最真实的用户访问情况来压测，可以通过修改JMeter环境中的自定义properties配置，将httpclient.reset_state_on_thread_group_iteration设置为true。
