記一次 JMeter 壓測(cè) HTTPS 性能問題

2023-01-05 11:44:43

本次解決了 JMeter5.0 版本以上壓測(cè) HTTPS 協(xié)議的性能問題。

問題背景

在使用 JMeter 壓測(cè)時(shí)，發(fā)現(xiàn)同一后端服務(wù)，在單機(jī) 500 并發(fā)下，HTTP 和 HTTPS 協(xié)議壓測(cè) RT 差距非常大。同時(shí)觀測(cè)后端服務(wù)各監(jiān)控指標(biāo)水位都很低，因此懷疑性能瓶頸在 JMeter 施壓客戶端。

問題分析

切入點(diǎn)：垃圾回收

首先在施壓機(jī)觀察到 CPU 使用率和內(nèi)存使用率都很高，詳細(xì)看下各線程 CPU、內(nèi)存使用情況：

top -Hp {pid}

發(fā)現(xiàn)進(jìn)程的 CPU 使用率將近打滿，其中 GC 線程 CPU 使用率很高

再看下 gc 的頻率和耗時(shí)，發(fā)現(xiàn)每秒都有 YoungGC，且累計(jì)耗時(shí)比較長，因此先從頻繁 GC 入手，定位問題。

java/bin/jstat -gcutil {pid} 1000

在壓測(cè)過程中，對(duì) JMeter 的運(yùn)行進(jìn)程做了 HeapDump 后，分析下堆內(nèi)存：

可以看到 cacheMap 對(duì)象占用了 93.3%的內(nèi)存，而它又被 SSLSessionContextImpl 類引用，分析下源碼，可以看出，每個(gè) SSLSessionContextImpl 對(duì)象構(gòu)造時(shí)，都會(huì)初始化 sessionHostPortCache 和 sessionCache 兩個(gè)軟引用 Cache。因?yàn)槭擒浺?，所以在?nèi)存不足時(shí) JVM 才會(huì)回收此類對(duì)象。

    // 默認(rèn)緩存大小
    private final static int DEFAULT_MAX_CACHE_SIZE = 20480;

    // package private
    SSLSessionContextImpl() {
        cacheLimit = getDefaultCacheLimit();    // default cache size，這里默認(rèn)是20480
        timeout = 86400;                        // default, 24 hours

        // use soft reference
        // 這里初始化了2個(gè)默認(rèn)大小20480的緩存，是頻繁GC的原因
        sessionCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
        sessionHostPortCache = Cache.newSoftMemoryCache(cacheLimit, timeout);
    }

    // 獲取默認(rèn)緩存大小
    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;
    }

通過上述代碼，發(fā)現(xiàn) sessionCache 和 sessionHostPortCache 緩存默認(rèn)大小是 DEFAULT_MAX_CACHE_SIZE，也就是 20480。對(duì)于我們壓測(cè)的場(chǎng)景來說，如果每次請(qǐng)求重新建立連接，那么就根本不需要這塊緩存。再看下代碼邏輯，發(fā)現(xiàn)其實(shí)可以通過
javax.net.ssl.sessionCacheSize 來設(shè)置緩存的大小，在 JMeter 啟動(dòng)時(shí)，添加 JVM 參數(shù)-Djavax.net.ssl.sessionCacheSize=1，將緩存大小設(shè)置為 1，重新壓測(cè)驗(yàn)證，觀察 GC。

可以看出，YGC 明顯變少了，從 1 秒 1 次，變成了 5-6 秒 1 次。那么觀察下壓測(cè)的 RT，結(jié)果。。。竟然還是 1800ms，本來 100ms 的服務(wù)被壓成 1800ms，看來問題不在于 SSLSession 的緩存。再回到 GC 的耗時(shí)分析部分，仔細(xì)看下，其實(shí) Full GC 只有 1 次，阻塞性的耗時(shí)并不多，Young GC 雖然頻繁，但阻塞時(shí)間很短，也不至于將 SSL 加解密的 CPU 計(jì)算時(shí)間片全部搶占?？雌饋韷毫褪菃渭兊?SSL 握手次數(shù)多，造成了性能瓶頸。

調(diào)整思路：為什么頻繁 SSL 握手

回到問題背景，我們是在做壓力測(cè)試，單機(jī)會(huì)跑很高的并發(fā)模擬用戶量，出于性能考慮，完全可以一次握手后共享 SSL 連接，后續(xù)不再握手，為什么 JMeter 會(huì)如此頻繁握手呢？

帶著這個(gè)問題，看了下 JMeter 官方文檔，果然有驚喜！

原來 JMeter 有 2 個(gè)開關(guān)在控制是否重置 SSL 上下文的選項(xiàng)，首先是
https.sessioncontext.shared 控制是否全局共享同一個(gè) SSLContext，如果設(shè)為 true，則各線程共享同一個(gè) SSL 上下文，這樣對(duì)施壓機(jī)性能壓力最低，但不能模擬真實(shí)多用戶 SSL 握手的情況。

第二個(gè)開關(guān)
httpclient.reset_state_on_thread_group_iteration 是線程組每次循環(huán)是否重置 SSL 上下文，5.0 之后默認(rèn)為true，也就是說每次循環(huán)都會(huì)重置 SSL 上下文，看來這就是導(dǎo)致 SSL 頻繁握手的原因。

問題驗(yàn)證

回歸測(cè)試

在 jmeter.properties 中將配置每個(gè)線程循環(huán)時(shí)，不重置 SSL 上下文，在 PTS 控制臺(tái)再次啟動(dòng)壓測(cè)，RT 直接下降 10 倍。

httpclient.reset_state_on_thread_group_iteration=false

修改前

修改后

源碼驗(yàn)證

下面從源碼層面分析下 JMeter 是怎么實(shí)現(xiàn)循環(huán)重置 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
    private void resetStateIfNeeded(JMeterVariables jMeterVariables, 
            HttpClientContext clientContext,
            Map<HttpClientKey, Pair<CloseableHttpClient, PoolingHttpClientConnectionManager>> mapHttpClientPerHttpClientKey){
        if (resetStateOnThreadGroupIteration.get()) {
            // 關(guān)閉當(dāng)前線程對(duì)應(yīng)連接池的超時(shí)、空閑連接，重置連接池狀態(tài)
            closeCurrentConnections(mapHttpClientPerHttpClientKey);
            // 移除Token
            clientContext.removeAttribute(HttpClientContext.USER_TOKEN);
            // 重置SSL上下文
            ((JsseSSLManager) SSLManager.getInstance()).resetContext();
            // 標(biāo)記置為false，保證一次循環(huán)中，只有第一個(gè)采樣器走進(jìn)此邏輯
            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 采樣器執(zhí)行時(shí)，都會(huì)調(diào)用 resetStateIfNeeded 方法，在進(jìn)入方法時(shí)讀取httpclient.reset_state_on_thread_group_iteration 配置，即 resetStateOnThreadGroupIteration。如果是 true，重置當(dāng)前線程的連接池狀態(tài)、重置 SSL 上下文，然后再將 resetStateOnThreadGroupIteration 置為 false。

因?yàn)?JMeter 的并發(fā)是基于線程實(shí)現(xiàn)的，resetStateOnThreadGroupIteration 這個(gè)開關(guān)放在 ThreadLocal 里，在每次循環(huán)開始時(shí)，會(huì)調(diào)用 notifyFirstSampleAfterLoopRestart 方法，重置開關(guān)，運(yùn)行一次后，強(qiáng)制把開關(guān)置為 false。這保證了每次循環(huán)只有第一個(gè)采樣器進(jìn)入此邏輯，也就是每次循環(huán)只執(zhí)行一次。

總結(jié)

本次解決了 JMeter5.0 版本以上壓測(cè) HTTPS 協(xié)議的性能問題，經(jīng)驗(yàn)總結(jié)如下：

如果希望施壓機(jī)發(fā)揮最大性能，可以將 https.sessioncontext.shared 設(shè)為 true，這樣所有線程會(huì)共享同一個(gè) SSL 上下文，不會(huì)頻繁握手，但是不能模擬真實(shí)情況下多用戶的場(chǎng)景。
如果希望模擬多個(gè)用戶，不停循環(huán)執(zhí)行某一個(gè)動(dòng)作，也就是一個(gè)線程組每次循環(huán)模擬同一個(gè)用戶的行為，可以將 httpclient.reset_state_on_thread_group_iteration 設(shè)置為 false，這樣也可以很大的提高單機(jī)壓測(cè) HTTPS 的性能。
如果希望每個(gè)線程組每次循環(huán)模擬不同用戶，那需要設(shè)置 httpclient.reset_state_on_thread_group_iteration=true，此時(shí)壓測(cè)會(huì)模擬多用戶頻繁 SSL 握手，施壓機(jī)性能最低，從經(jīng)驗(yàn)來看，單機(jī)上限 50 并發(fā)左右。這也是 JMeter5.0 版本之后的默認(rèn)設(shè)置。

責(zé)任編輯：張燕妮來源：阿里云云棲號(hào)