作者：拂衣
问题布景
在运用 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 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 之后默许为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
*/
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 压测东西 [ 1] 支撑原生 JMeter 脚本，并且在 HTTPS 的压测中已将 httpclient.reset_state_on_thread_group_iteration 默许设置为 false，极大进步压测 HTTPS 时施压机功能，节约压测成本。假如模仿最实在的用户访问情况来压测，能够经过修正 JMeter 环境中的自定义 properties 装备 [ 2] ，将 httpclient.reset_state_on_thread_group_iteration 设置为 true。
除此以外，阿里云 JMeter 压测有以下优势：
- 零运维成本支撑散布式压测，即压即用
- 压测中检查秒级监控，实时观测体系功能水位
- 支撑 RPS 形式，直观衡量体系吞吐量
- 全球地域发起百万级并发流量，模仿实在用户散布
- 支撑阿里云 VPC 压测，一键打通云上内网环境
- 支撑 JMeter 客户端插件，本地快速发起云端压测
更多沟通，欢迎进钉钉群沟通，PTS 用户沟通群号：11774967
一起，PTS 全新售卖方式来袭，基础版价格直降 50%！百万并发价格只需 6200！更有新用户 0.99 体验版、VPC 压测专属版，欢迎我们选购！
参考链接：
[1]阿里云 PTS 压测东西
pts.console.aliyun.com/#/jmeter/cr…
[2] 自定义 properties 装备
common-buy.aliyun.com/?commodityC…
点击此处，前往功能测验服务 PTS 官网检查更多概况！
