1. 簡介
JSF 業(yè)務(wù)線程池使用 JDK 的線程池技術(shù),缺省情況下采用 Cached 模式(核心線程數(shù) 20,最大線程數(shù) 200)。此外,還提供了 Fixed 固定線程大小的模式,兩種模式均可設(shè)置請求隊列大小。
本文旨在通過一個簡化場景(“單服務(wù)應(yīng)用”)下的負(fù)載測試,為 “JSF 業(yè)務(wù)線程池大小配置” 提供基準(zhǔn)測試結(jié)果,并形成一些普遍適用的結(jié)論。
本文的目標(biāo)讀者包括需要合理配置 JSF 線程大小的壓測工程師、開發(fā)部署運(yùn)維工程師以及架構(gòu)師。
本文不涉及 JSF 服務(wù)端的其他配置項,也不針對 “復(fù)合服務(wù)應(yīng)用” 的合理配置進(jìn)行探討。你可以利用本文提供的結(jié)論,作為設(shè)計壓測用例或評估業(yè)務(wù)線程池大小的基本方法的參考,以便在實踐中合理配置 JSF 業(yè)務(wù)線程池大小。需要注意的是,JSF 業(yè)務(wù)線程池大小的合理配置應(yīng)該基于高保真的負(fù)載測試結(jié)果。
“單服務(wù)應(yīng)用” 指應(yīng)用僅包含一個提供接口,且接口中僅有一個方法。 “復(fù)合服務(wù)應(yīng)用” 則指應(yīng)用包含多個提供接口或一個接口中含有多個方法。
2. 測試用例說明
本次基準(zhǔn)測試選取了 USF3.0 權(quán)限系統(tǒng),將其定制化為一個單一的服務(wù)提供者,僅對該提供者的一個方法進(jìn)行了測試,因此可以看作是一個 “單服務(wù)應(yīng)用”。
測試中將 CPU 作為基準(zhǔn)測試的核心資源,并考慮到 JVM 垃圾收集器的影響,采用了簡單的測試數(shù)據(jù)以保證服務(wù)每次調(diào)用的一致性,并確保 YGC 具有規(guī)律性(即固定調(diào)用量會導(dǎo)致一次 30+ms 的 YGC),無 FGC 的影響。
測試用例的設(shè)計中,所有依賴的服務(wù)資源都無限制,以確保測試過程中服務(wù)的可用率達(dá)到 100%。我們的關(guān)鍵性能指標(biāo)是 TP99,即服務(wù)響應(yīng)時長的 99% 必須小于 10ms。
為了測試不同線程池模式下的性能表現(xiàn),我們使用了 JSF 線程池的 Cached 和 Fixed 兩種模式,并針對每種模式進(jìn)行了多組測試,以得出在滿足 TP99<10ms 的前提下,系統(tǒng)最大的負(fù)載情況。
測試應(yīng)用:USF3.0 權(quán)限系統(tǒng) (定制化處理) 測試服務(wù):com.jd.susf.service.api.SusfPermissionService#findUserInfo,根據(jù)用戶信息從 Redis 中查詢一條數(shù)據(jù)返回的服務(wù)。
硬件配置:單臺 4C 8G 測試方法:在 Forcebot 系統(tǒng)采用了階梯發(fā)壓的方式對 JSF 業(yè)務(wù)線程池在 Cached 和 Fixed 模式下進(jìn)行了系統(tǒng)負(fù)載測試 擬定 SLA 要求:服務(wù)響應(yīng)時長的 TP99<10ms
注:我們對 USF3.0 權(quán)限系統(tǒng)進(jìn)行了定制,調(diào)整了服務(wù)提供方的配置數(shù)據(jù),僅保留了 com.jd.susf.service.api.SusfPermissionService。
3. 測試結(jié)果及分析
3.1.cached 線程池的系統(tǒng)負(fù)載
圖:JSF 默認(rèn)線程池 (cached, threads=200) 在不同并發(fā)用戶數(shù) (1-200) 下的系統(tǒng)負(fù)載圖
并發(fā)用戶數(shù) | TP99 | 吞吐量 TPS | CPU 利用率 (%) |
---|---|---|---|
1~23 | <8ms | 線性增長 | 線性增長 |
24 | 8ms | 6553 | 99.62 |
25 | 11ms | 6607 | 99.83 |
26~79 | 迅速增長 | 緩慢增長 | 99+ |
80 | 74ms | 6928 | 99.82 |
81~199 | 緩慢增加 | 緩慢下降 | 99.82 |
200 | 99ms | 6230 | 99.94 |
小結(jié):默認(rèn)的 JSF 線程池配置存在很大的風(fēng)險。系統(tǒng)最大可支持 24 個并發(fā),超過 24 個并發(fā) SLA 就無法滿足。
3.2 fixed 線程池 (隊列) 的系統(tǒng)負(fù)載
圖:JSF 固定線程池 (fixed + 隊列) 在不同并發(fā)用戶數(shù) (1-50) 下的系統(tǒng)負(fù)載圖
JSF 業(yè)務(wù)線程數(shù) | 可支持的最大并發(fā)用戶數(shù) | TP 值 (50/90/99/999) | 吞吐量 (TPS) | CPU 最大利用率(%) |
---|---|---|---|---|
4 | 11 | 7/8/10/18 | 1531 | 27.67 |
8 | 25 | 8/8/10/18 | 3113 | 46.45 |
16 | 50 | 8/8/10/21 | 6228 | 87.97 |
20 | 23 | 3/4/10/15 | 6409 | 99.92 |
24 | 22 | 3/4/7/15 | 6178 | 99.86 |
25 | 22 | 3/4/6/15 | 6182 | 98.83 |
表:JSF 固定業(yè)務(wù)線程池 (fixed + 隊列) 在滿足 TP99<10ms 的系統(tǒng)最大負(fù)載(最大并發(fā)用戶數(shù))
小結(jié): ① 在 fixed 線程模式下,CPU 的利用率存在使用上限。
② 隊列的使用可以有效增加系統(tǒng)對并發(fā)量的支持,同時也會帶來吞吐量的提升。然而,由于任務(wù)在隊列中等待,服務(wù)的響應(yīng)時間會出現(xiàn) “水漲船高” 的現(xiàn)象,存在一定風(fēng)險。
3.3 fixed 線程池的系統(tǒng)負(fù)載
圖:JSF 固定線程池 (fixed) 模式下,系統(tǒng)最大并發(fā)用戶數(shù)時的系統(tǒng)負(fù)載
JSF 業(yè)務(wù)線程數(shù) | 并發(fā)用戶數(shù) | TP99 | 吞吐量 (TPS) | CPU 最大利用率(%) |
---|---|---|---|---|
4 | 4 | 5 | 1063 | 20.26 |
8 | 8 | 5 | 2216 | 36.62 |
16 | 16 | 6 | 4262 | 68.56 |
20 | 20 | 5 | 5550 | 86.22 |
24 | 24 | 8 | 6711 | 99.62 |
25 | 25 | 16 | 6644 | 98.77 |
26 | 26 | 19 | 6744 | 99.93 |
小結(jié):綜合固定線程池 (fixed) 的性能表現(xiàn),需要設(shè)置一個合理的線程數(shù)大小來平衡 CPU 資源的充分利用和滿足 SLA 的需求,線程數(shù)過小會導(dǎo)致 CPU 資源浪費(fèi),線程數(shù)過大則無法滿足 SLA
4. 結(jié)論
根據(jù)測試結(jié)果和數(shù)據(jù)分析,我們得出以下結(jié)論:
JSF 線程池的默認(rèn)配置在并發(fā)量高的場景下存在風(fēng)險:所有線上生產(chǎn)環(huán)境中的 JSF 服務(wù)所在的服務(wù)器,很少有能夠在 200 個線程的情況下還能夠滿足 SLA 的。最大 200 個線程的線程池配置,將服務(wù)器置于 “并發(fā)量高的場景下被壓垮” 的風(fēng)險中。線程池大小的合理配置應(yīng)該來自高保真的負(fù)載測試。
足量的線程數(shù)才能保證資源 (CPU) 的利用率:業(yè)務(wù)型的服務(wù)通常都存在一定的 IO 操作(網(wǎng)絡(luò),磁盤等),線程執(zhí)行過程中會發(fā)生等待,CPU 利用率不高,需要增加并發(fā)的線程數(shù)量,讓更多的線程參與 CPU 的分配,才能提高 CPU 的利用率。服務(wù)中 IO 操作越多,等待時長越長,需要的并發(fā)線程就越多。對于有 IO 操作的業(yè)務(wù)型服務(wù),負(fù)載測試的線程數(shù)可以從 2N(N 是服務(wù)器的 CPU 核數(shù))開始。
過多的線程數(shù)只會降低系統(tǒng)的 SLA:當(dāng)線程數(shù)已能 100% 利用 CPU 后,增加線程數(shù),線程就無法獲取足夠的 CPU 分配,這樣服務(wù)的響應(yīng)時間就會增大。
在一定范圍內(nèi),TP99 還可能滿足 SLA 的要求,系統(tǒng)的吞吐量也會有少量的增加。再持續(xù)增加線程數(shù),TP99 就無法滿足系統(tǒng)的要求,系統(tǒng)的吞吐量也會開始下降。
固定的線程數(shù)可以保護(hù)系統(tǒng)需要承擔(dān)的負(fù)載能力:固定線程數(shù)可以保證系統(tǒng)對 CPU 的利用率限定在一定的負(fù)載范圍內(nèi),保護(hù)系統(tǒng)穩(wěn)定運(yùn)行,保證響應(yīng)時間 TP99,但也限定了系統(tǒng)的并發(fā)能力。
合理設(shè)置隊列大小可以增加系統(tǒng)的并發(fā)度,也不會影響系統(tǒng) TP99,但會整體拉高服務(wù)的響應(yīng)時間,出現(xiàn)不穩(wěn)定性的變化,存在風(fēng)險。
讓 CPU100% 的高負(fù)載運(yùn)行:通常服務(wù)對外的 SLA 承諾通常高于服務(wù)真實的性能,這是因為我們考慮了基礎(chǔ)設(shè)施及依賴服務(wù)的不穩(wěn)定性。
因此,即使 CPU 已經(jīng)達(dá)到了 100%,我們?nèi)匀豢梢栽黾右欢〝?shù)量的線程數(shù),而不會影響對外的響應(yīng)時間 TP99 的承諾。這樣可以提高系統(tǒng)的并發(fā)能力。雖然系統(tǒng)可以在高負(fù)載下運(yùn)行,但我們需要進(jìn)一步進(jìn)行穩(wěn)定性測試,以提高系統(tǒng)的可靠性。
綜上所述,線程池大小的合理配置需要結(jié)合業(yè)務(wù)需求和系統(tǒng)資源情況進(jìn)行評估和測試,并預(yù)留合理的 buffer 空間,以保證系統(tǒng)穩(wěn)定運(yùn)行和滿足用戶的 SLA。
5. 附錄
附錄一:統(tǒng)計指標(biāo)及術(shù)語說明
并發(fā)用戶數(shù):同時發(fā)起請求的用戶數(shù)。
TP 值 (50/90/99/999):客戶端的 TP 值,單位 ms,數(shù)據(jù)來源于 Forcebot。
吞吐量 TPS:數(shù)據(jù)來源于 Forcebot。
CPU 利用率 (%):數(shù)據(jù)來源于 PFinder。
JSF 業(yè)務(wù)線程數(shù):JSF 業(yè)務(wù)線程池的線程數(shù),如:
fixed/cached:JSF 業(yè)務(wù)線程池的線程池類型,如:
審核編輯:劉清
-
SLA
+關(guān)注
關(guān)注
1文章
54瀏覽量
18265 -
USF
+關(guān)注
關(guān)注
0文章
2瀏覽量
8054 -
TPS
+關(guān)注
關(guān)注
0文章
83瀏覽量
36216 -
JSF
+關(guān)注
關(guān)注
0文章
11瀏覽量
7746 -
JVM
+關(guān)注
關(guān)注
0文章
158瀏覽量
12220
原文標(biāo)題:談?wù)凧SF業(yè)務(wù)線程池的大小配置
文章出處:【微信號:OSC開源社區(qū),微信公眾號:OSC開源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論