問題背景
在使用 JMeter 壓測時，發現同一后端服務，在單機 500 并發下，HTTP 和 HTTPS 協議壓測 RT 差距非常大，同時觀測后端服務各監控指標水位都很低，因此懷疑性能瓶頸在 JMeter 施壓客戶端，
問題分析
切入點：垃圾回收
首先在施壓機觀察到 CPU 使用率和記憶體使用率都很高，詳細看下各執行緒 CPU、記憶體使用情況：
top -Hp {pid}
發現行程的 CPU 使用率將近打滿，其中 GC 執行緒 CPU 使用率很高
再看下 gc 的頻率和耗時，發現每秒都有 YoungGC，且累計耗時比較長，因此先從頻繁 GC 入手，定位問題，
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 引數-D javax.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 背景關系的，代碼如下：
/** * 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 版本之后的默認設定，
作 者 | 拂衣
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Remember-a-JMeter-stress-test-HTTPS-performance-problem.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/500086.html
標籤：其他
上一篇：【Unity學習筆記】掌握MoneBehavior中的重要屬性、方法
下一篇：OpenCV視頻防抖技術決議