問題背景
在使用 JMeter 壓測時，發(fā)現(xiàn)同一后端服務，在單機 500 并發(fā)下，HTTP 和 HTTPS 協(xié)議壓測 RT 差距非常大。同時觀測后端服務各監(jiān)控指標水位都很低，因此懷疑性能瓶頸在 JMeter 施壓客戶端。
問題分析
切入點：垃圾回收
首先在施壓機觀察到 CPU 使用率和內(nèi)存使用率都很高，詳細看下各線程 CPU、內(nèi)存使用情況：
top -Hp {pid}發(fā)現(xiàn)進程的 CPU 使用率將近打滿，其中 GC 線程 CPU 使用率很高
再看下 gc 的頻率和耗時，發(fā)現(xiàn)每秒都有 YoungGC，且累計耗時比較長，因此先從頻繁 GC 入手，定位問題。
java/bin/jstat -gcutil {pid} 1000
在壓測過程中，對 JMeter 的運行進程做了 HeapDump 后，分析下堆內(nèi)存：
可以看到 cacheMap 對象占用了 93.3%的內(nèi)存，而它又被 SSLSessionContextImpl 類引用，分析下源碼，可以看出，每個 SSLSessionContextImpl 對象構造時，都會初始化 sessionHostPortCache 和 sessionCache 兩個軟引用 Cache。因為是軟引用，所以在內(nèi)存不足時 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;
}通過上述代碼，發(fā)現(xiàn) sessionCache 和 sessionHostPortCache 緩存默認大小是 DEFAULT_MAX_CACHE_SIZE，也就是 20480。對于我們壓測的場景來說，如果每次請求重新建立連接，那么就根本不需要這塊緩存。再看下代碼邏輯，發(fā)現(xiàn)其實可以通過 javax.net.ssl.sessionCacheSize 來設置緩存的大小，在 JMeter 啟動時，添加 JVM 參數(shù)-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 握手次數(shù)多，造成了性能瓶頸。
調整思路：為什么頻繁 SSL 握手
回到問題背景，我們是在做壓力測試，單機會跑很高的并發(fā)模擬用戶量，出于性能考慮，完全可以一次握手后共享 SSL 連接，后續(xù)不再握手，為什么 JMeter 會如此頻繁握手呢？
帶著這個問題，看了下 JMeter 官方文檔，果然有驚喜！
原來 JMeter 有 2 個開關在控制是否重置 SSL 上下文的選項，首先是 https.sessioncontext.shared 控制是否全局共享同一個 SSLContext，如果設為 true，則各線程共享同一個 SSL 上下文，這樣對施壓機性能壓力最低，但不能模擬真實多用戶 SSL 握手的情況。
第二個開關 httpclient.reset_state_on_thread_group_iteration 是線程組每次循環(huán)是否重置 SSL 上下文，5.0 之后默認為true，也就是說每次循環(huán)都會重置 SSL 上下文，看來這就是導致 SSL 頻繁握手的原因。
問題驗證
回歸測試
在 jmeter.properties 中將配置每個線程循環(huán)時，不重置 SSL 上下文，在 PTS 控制臺再次啟動壓測，RT 直接下降 10 倍。
httpclient.reset_state_on_thread_group_iteration=false
修改前
修改后
源碼驗證
下面從源碼層面分析下 JMeter 是怎么實現(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 PoolingHttpClientConnectionManager}
*/
private void resetStateIfNeeded(JMeterVariables jMeterVariables,
HttpClientContext clientContext,
Map<HttpClientKey, Pair<CloseableHttpClient, PoolingHttpClientConnectionManager>> mapHttpClientPerHttpClientKey) {
if (resetStateOnThreadGroupIteration.get()) {
// 關閉當前線程對應連接池的超時、空閑連接，重置連接池狀態(tài)
closeCurrentConnections(mapHttpClientPerHttpClientKey);
// 移除Token
clientContext.removeAttribute(HttpClientContext.USER_TOKEN);
// 重置SSL上下文
((JsseSSLManager) SSLManager.getInstance()).resetContext();
// 標記置為false，保證一次循環(huá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í)行時，都會調用 resetStateIfNeeded 方法，在進入方法時讀取 httpclient.reset_state_on_thread_group_iteration 配置，即 resetStateOnThreadGroupIteration。如果是 true，重置當前線程的連接池狀態(tài)、重置 SSL 上下文，然后再將 resetStateOnThreadGroupIteration 置為 false。
因為 JMeter 的并發(fā)是基于線程實現(xiàn)的，resetStateOnThreadGroupIteration 這個開關放在 ThreadLocal 里，在每次循環(huán)開始時，會調用 notifyFirstSampleAfterLoopRestart 方法，重置開關，運行一次后，強制把開關置為 false。這保證了每次循環(huán)只有第一個采樣器進入此邏輯，也就是每次循環(huán)只執(zhí)行一次。
總結
本次解決了 JMeter5.0 版本以上壓測 HTTPS 協(xié)議的性能問題，經(jīng)驗總結如下：
- 如果希望施壓機發(fā)揮最大性能，可以將 https.sessioncontext.shared 設為 true，這樣所有線程會共享同一個 SSL 上下文，不會頻繁握手，但是不能模擬真實情況下多用戶的場景。
- 如果希望模擬多個用戶，不停循環(huán)執(zhí)行某一個動作，也就是一個線程組每次循環(huán)模擬同一個用戶的行為，可以將 httpclient.reset_state_on_thread_group_iteration 設置為 false，這樣也可以很大的提高單機壓測 HTTPS 的性能。
- 如果希望每個線程組每次循環(huán)模擬不同用戶，那需要設置 httpclient.reset_state_on_thread_group_iteration=true，此時壓測會模擬多用戶頻繁 SSL 握手，施壓機性能最低，從經(jīng)驗來看，單機上限 50 并發(fā)左右。這也是 JMeter5.0 版本之后的默認設置。
阿里云 JMeter 壓測
阿里云 PTS 壓測工具[1]支持原生 JMeter 腳本，并且在 HTTPS 的壓測中已將 httpclient.reset_state_on_thread_group_iteration 默認設置為 false，極大提高壓測 HTTPS 時施壓機性能，節(jié)省壓測成本。如果模擬最真實的用戶訪問情況來壓測，可以通過修改 JMeter 環(huán)境中的自定義 properties 配置[2]，將 httpclient.reset_state_on_thread_group_iteration 設置為 true。
除此以外，阿里云 JMeter 壓測有以下優(yōu)勢：
- 零運維成本支持分布式壓測，即壓即用
- 壓測中查看秒級監(jiān)控，實時觀測系統(tǒng)性能水位
- 支持 RPS 模式，直觀衡量系統(tǒng)吞吐量
- 全球地域發(fā)起百萬級并發(fā)流量，模擬真實用戶分布
- 支持阿里云 VPC 壓測，一鍵打通云上內(nèi)網(wǎng)環(huán)境
- 支持 JMeter 客戶端插件，本地快速發(fā)起云端壓測
-
?總結
如果你對此文有任何疑問，如果你也需要接口項目實戰(zhàn)，如果你對軟件測試、接口測試、自動化測試、面試經(jīng)驗交流感興趣歡迎加入我們，加入方式在文章的最后面
??自動化測試相關教程推薦：
2023最新自動化測試自學教程新手小白26天入門最詳細教程,目前已有300多人通過學習這套教程入職大廠?。嗶哩嗶哩_bilibili
2023最新合集Python自動化測試開發(fā)框架【全棧/實戰(zhàn)/教程】合集精華，學完年薪40W+_嗶哩嗶哩_bilibili
測試開發(fā)相關教程推薦
2023全網(wǎng)最牛，字節(jié)測試開發(fā)大佬現(xiàn)場教學，從零開始教你成為年薪百萬的測試開發(fā)工程師_嗶哩嗶哩_bilibili
postman/jmeter/fiddler測試工具類教程推薦
講的最詳細JMeter接口測試/接口自動化測試項目實戰(zhàn)合集教程，學jmeter接口測試一套教程就夠了??！_嗶哩嗶哩_bilibili
2023自學fiddler抓包，請一定要看完【如何1天學會fiddler抓包】的全網(wǎng)最詳細視頻教程！！_嗶哩嗶哩_bilibili
2023全網(wǎng)封神，B站講的最詳細的Postman接口測試實戰(zhàn)教學，小白都能學會_嗶哩嗶哩_bilibili
??總結：
?光學理論是沒用的，要學會跟著一起敲，要動手實操，才能將自己的所學運用到實際當中去，這時候可以搞點實戰(zhàn)案例來學習。
???
???如果對你有幫助的話，點個贊收個藏，給作者一個鼓勵。也方便你下次能夠快速查找。
如有不懂還要咨詢下方小卡片，博主也希望和志同道合的測試人員一起學習進步
在適當?shù)哪挲g，選擇適當?shù)膷徫?，盡量去發(fā)揮好自己的優(yōu)勢。
我的自動化測試開發(fā)之路，一路走來都離不每個階段的計劃，因為自己喜歡規(guī)劃和總結，
測試開發(fā)視頻教程、學習筆記領取傳送門??！
?文章來源地址http://www.zghlxwxcb.cn/news/detail-811910.html
?文章來源：http://www.zghlxwxcb.cn/news/detail-811910.html
?
到了這里，關于記一次 JMeter 壓測 HTTPS 性能問題的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
