记一次 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 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 压测工具
http://pts.console.aliyun.com/#/jmeter/create
[2] 自定义 properties 配置
http://common-buy.aliyun.com/?commodityCode=pts#/open
点击此处,前往性能测试服务 PTS 官网查看更多详情!
- 启动!阿里巴巴编程之夏2022
- 云原生混部最后一道防线:节点水位线设计
- OpenKruise v1.2:新增 PersistentPodState 实现有状态 Pod 拓扑固定与 IP 复用
- Serverless Job——传统任务新变革
- 首评 | 阿里云顺利完成国内首个云原生安全成熟度评估
- Serverless Job——传统任务新变革
- 阿里云发布性能测试 PTS 2.0:低成本、高效率、多场景压测,业务稳定性保障利器
- ZooKeeper 在阿里巴巴的服务形态演进
- OpenYurt v0.7.0 版本解读:无侵入的跨网络域解决方案 Raven
- K8s 网关选型初判:Nginx 还是 Envoy?
- K8s 网关选型初判:Nginx 还是 Envoy?
- ZooKeeper 在阿里巴巴的服务形态演进
- 面向高校 | “云原生技术应用与实践”示范课程项目开放申报
- 硬之城获阿里云首批产品生态集成认证,携手阿里云共建新合作
- 基于阿里云 ASK 的 Istio 微服务应用部署初探
- Seata 1.5.1 重磅发布,支持用户控制台,企业版正式免费公测
- OpenYurt v0.7.0 版本解读:无侵入的跨网络域解决方案 Raven
- 最佳实践|从Producer 到 Consumer,如何有效监控 Kafka
- 报名进入尾声,赶快申请加入 sealer 开源之夏吧!
- OpenClusterManagement 开源之夏 2022 来了