记一次 JMeter 压测 HTTPS 性能问题，2024年最新一个软件测试程序员的面试心得

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

• }
• • // 获取默认缓存大小
• 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 上下文的，代码如下：

1. /**
2. * Whether SSL State/Context should be reset
3. * Shared state for any HC based implementation, because SSL contexts are the same
4. */
5. protected static final ThreadLocal<Boolean> resetStateOnThreadGroupIteration =
6. ThreadLocal.withInitial(() -> Boolean.FALSE);
7. • • /**

• * 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 协议的性能问题，经验总结如下：

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 版本之后的默认设置。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
可以添加V获取：vip1024b （备注软件测试）**
[外链图片转存中…(img-pBJK7EVv-1713601963475)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！