开发者社区> urwoods> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

记一次JMeter压测HTTPS性能问题

简介: 问题背景在使用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。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Java 应用压测性能问题定位经验分享
问题千千万,但只要修练了足够深厚的内功,形成一套属于自己的排查问题思路和打法,再加上一套支撑问题排查的工具,凭借已有的经验还有偶发到来的那一丝丝灵感,相信所有的问题都会迎刃而解。
1190 0
JMeter - 压测模拟并发
JMeter - 压测模拟并发
11 0
使用 Haproxy + Nginx 实现高可用
Haproxy 是目前比较流行的一种集群调度工具,同类集群调度器工具有很多,如 LVS 和 Nginx。相比较而言,LVS 性能最好,但是搭建相对复杂;Nginx 的 upstream 模块虽然支持集群功能,但是对集群节点健康检查功能不强,性能没有 Haproxy 好。
67 0
LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?
90 0
8个惊艳的 HTML5 和 JavaScript 特效
  这篇文章向大家展示8个惊艳的 HTML5 和 JavaScript 特效。作为下一代网页语言,HTML5 拥有很多让人期待已久的新特性,越来越多的开发人员开始使用 HTML5 来制作各种交互性强、效果丰富的 Web 应用。
1049 0
+关注
2
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载