共计 5375 个字符，预计需要花费 14 分钟才能阅读完成。
简介：在应用 JMeter 压测时，发现同一后端服务，在单机 500 并发下，HTTP 和 HTTPS 协定压测 RT 差距十分大。同时观测后端服务各监控指标水位都很低，因而狐疑性能瓶颈在 JMeter 施压客户端。
作者：拂衣
问题背景
在应用 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 客户端插件，本地疾速发动云端压测
原文链接
本文为阿里云原创内容，未经容许不得转载。
