記一次 JMeter 壓測 HTTPS 效能問題

語言: CN / TW / HK

作者:拂衣

問題背景

在使用 JMeter 壓測時,發現同一後端服務,在單機 500 併發下,HTTP 和 HTTPS 協議壓測 RT 差距非常大。同時觀測後端服務各監控指標水位都很低,因此懷疑效能瓶頸在 JMeter 施壓客戶端。

問題分析

切入點:垃圾回收

首先在施壓機觀察到 CPU 使用率和記憶體使用率都很高,詳細看下各執行緒 CPU、記憶體使用情況:

top -Hp {pid}

發現程序的 CPU 使用率將近打滿,其中 GC 執行緒 CPU 使用率很高

\

1.png

再看下 gc 的頻率和耗時,發現每秒都有 YoungGC,且累計耗時比較長,因此先從頻繁 GC 入手,定位問題。

java/bin/jstat -gcutil {pid} 1000

2.png

在壓測過程中,對 JMeter 的執行程序做了 HeapDump 後,分析下堆記憶體:

3.png

可以看到 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。

4.png

可以看出,YGC 明顯變少了,從 1 秒 1 次,變成了 5-6 秒 1 次。那麼觀察下壓測的 RT,結果。。。竟然還是 1800ms,本來 100ms 的服務被壓成 1800ms,看來問題不在於 SSLSession 的快取。再回到 GC 的耗時分析部分,仔細看下,其實 Full GC 只有 1 次,阻塞性的耗時並不多,Young GC 雖然頻繁,但阻塞時間很短,也不至於將 SSL 加解密的 CPU 計算時間片全部搶佔。看起來壓力就是單純的 SSL 握手次數多,造成了效能瓶頸。

調整思路:為什麼頻繁 SSL 握手

回到問題背景,我們是在做壓力測試,單機會跑很高的併發模擬使用者量,出於效能考慮,完全可以一次握手後共享 SSL 連線,後續不再握手,為什麼 JMeter 會如此頻繁握手呢?

帶著這個問題,看了下 JMeter 官方文件,果然有驚喜!

5.png

原來 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

6.png

修改前

7.png

修改後

原始碼驗證

下面從原始碼層面分析下 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 上下文,不會頻繁握手,但是不能模擬真實情況下多使用者的場景。

  2. 如果希望模擬多個使用者,不停迴圈執行某一個動作,也就是一個執行緒組每次迴圈模擬同一個使用者的行為,可以將 httpclient.reset_state_on_thread_group_iteration 設定為 false,這樣也可以很大的提高單機壓測 HTTPS 的效能。

  3. 如果希望每個執行緒組每次迴圈模擬不同使用者,那需要設定 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 壓測專屬版,歡迎大家選購!

8.png

參考連結:

[1] 阿里雲 PTS 壓測工具

https://pts.console.aliyun.com/#/jmeter/create

[2] 自定義 properties 配置

https://common-buy.aliyun.com/?commodityCode=pts#/open

點選此處,前往效能測試服務 PTS 官網檢視更多詳情!