记一次JMeter压测HTTPS性能问题

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 问题背景在使用JMeter压测时,发现同一后端服务,在单机500并发下,HTTP和HTTPS协议压测RT差距非常大。同时观测后端服务各监控指标水位都很低,因此怀疑性能瓶颈在JMeter施压客户端。问题分析切入点:垃圾回收首先在施压机观察到CPU使用率和内存使用率都很高,详细看下各线程CPU、内存使用情况:top -Hp {pid}发现进程的CPU使用率将近打满,其中GC线程CPU使用率很高再看下g

问题背景

在使用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协议的性能问题,经验总结如下:

  1. 如果希望施压机发挥最大性能,可以将https.sessioncontext.shared设为true,这样所有线程会共享同一个SSL上下文,不会频繁握手,但是不能模拟真实情况下多用户的场景。

  1. 如果希望模拟多个用户,不停循环执行某一个动作,也就是一个线程组每次循环模拟同一个用户的行为,可以将httpclient.reset_state_on_thread_group_iteration设置为false,这样也可以很大的提高单机压测HTTPS的性能。

  1. 如果希望每个线程组每次循环模拟不同用户,那需要设置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。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
15天前
|
存储 监控 数据可视化
性能测试:主流性能剖析工具介绍
**性能剖析**是识别应用性能瓶颈的关键,涉及指标收集、热点分析、优化建议及可视化报告。常用工具有:**JConsole**监控JVM,**VisualVM**多合一分析,**JStack**分析线程,**FlameGraph**展示CPU耗时,**SkyWalking**分布式跟踪,**Zipkin**追踪服务延迟。这些工具助力开发人员提升系统响应速度和资源效率。
19 1
|
27天前
|
测试技术 Windows
软件测试之 性能测试 性能测试基础指标 Loadrunner、Jmeter等工具(下)
软件测试之 性能测试 性能测试基础指标 Loadrunner、Jmeter等工具(下)
26 2
|
27天前
|
测试技术 程序员
软件测试之 性能测试 性能测试基础指标 Loadrunner、Jmeter等工具(上)
软件测试之 性能测试 性能测试基础指标 Loadrunner、Jmeter等工具(上)
38 1
|
29天前
|
Linux Windows
Jmeter设置中文语言和配置https
Jmeter设置中文语言和配置https
46 0
Jmeter设置中文语言和配置https
|
2月前
|
前端开发 Java Linux
性能工具之 Jmeter 通过 SpringBoot 工程启动
【5月更文挑战第22天】性能工具之 Jmeter 通过 SpringBoot 工程启动
53 8
性能工具之 Jmeter 通过 SpringBoot 工程启动
|
2月前
|
监控 数据可视化 测试技术
性能工具之JMeter+InfluxDB+Grafana打造压测可视化实时监控
【5月更文挑战第23天】性能工具之JMeter+InfluxDB+Grafana打造压测可视化实时监控
97 6
性能工具之JMeter+InfluxDB+Grafana打造压测可视化实时监控
|
14天前
|
监控 数据可视化 测试技术
性能测试:性能测试流程与方法
**性能测试流程与方法概述:** 本文介绍了性能测试的关键步骤,包括现状分析、指标获取、用户场景定义、验收标准设定、测试计划编写、压力环境准备、执行压测、监控、结果分析、报告编写及改进建议。测试方法涉及并发模式(虚拟用户)和RPS模式(吞吐量),确保系统在不同负载下的稳定性和效率。
15 0
|
24天前
|
关系型数据库 MySQL 测试技术
《阿里云产品四月刊》—瑶池数据库微课堂|RDS MySQL 经济版 vs 自建 MySQL 性能压测与性价比分析
阿里云瑶池数据库云原生化和一体化产品能力升级,多款产品更新迭代
|
26天前
|
JSON Java 测试技术
必知的技术知识:Jmeter压测工具使用手册(完整版)
必知的技术知识:Jmeter压测工具使用手册(完整版)
|
1月前
|
监控 数据可视化 Java
掌握 JMeter 插件管理器:提升性能测试的利器
Apache JMeter 是一款强大的性能测试工具,其灵活性和扩展性使其在性能测试领域广受欢迎。JMeter 插件管理器(JMeter Plugins Manager)为用户提供了一个方便的平台来安装、更新和管理各种插件,从而大大扩展了 JMeter 的功能。
32 0