背景介紹 JSF(京東服務框架,類似dubbo)預設配置了可伸縮的最大到200的工作線程池,每一個向外提供的服務都在其中運行(這裡我們是服務端),這些服務內部調用外部依賴時(這裡我們是客戶端)一般是同步調用,不單獨限制調用併發量,因為同步調用時會阻塞原服務線程,因此實際上所有外部調用共用了JSF的2 ...
背景介紹
JSF(京東服務框架,類似dubbo)預設配置了可伸縮的最大到200的工作線程池,每一個向外提供的服務都在其中運行(這裡我們是服務端),這些服務內部調用外部依賴時(這裡我們是客戶端)一般是同步調用,不單獨限制調用併發量,因為同步調用時會阻塞原服務線程,因此實際上所有外部調用共用了JSF的200工作線程池。
Hystrix框架為了隔離依賴相互影響,預設使用了線程隔離機制,為每個依賴提供一個小的線程池,如果該線程池已滿新的調用將被立即拒絕,預設不排隊加快失敗返回。這與JSF原來的機制非常不一樣,我們的問題是:
額外的線程池是否有太大的性能開銷?
線程池大小設置多少合理?
希望通過本次測試調研得到答案。
用例介紹
構造兩個介面,分別調用原生mock方法和調用經過hystrix包裝的mock方法,兩個mock方法內部都是一個Thread.sleep,根據不同參數模擬不同性能的外部依賴調用。其中JSF線程池為預設值最大200,hystrix單個線程池大小為預設值10,預設超時1000ms,為了排除干擾禁用斷路器。根據兩個介面、不同mock參數和不同壓測線程數組合構造出共11個測試用例。
部署單台只包括這兩個介面的生產機器,使用分散式壓測平臺(多台Jmeter)對其進行壓測,主要通過介面內部的UMP進行性能和JVM狀態監控,JVM使用JDK8並且開啟G1收集器(壓測中無full gc)。
@Service
public class MockJsfServiceRef {
@HystrixCommand(commandProperties = {
@HystrixProperty(name = "circuitBreaker.enabled", value = "false")
})
public String doHystrix(Integer param) throws Exception {
Thread.sleep(param);
return "1";
}
public String doNative(Integer param) throws Exception {
Thread.sleep(param);
return "1";
}
}
壓測數據及解析
首先前8個用例和結果數據體現了在相同的正常壓力下(10線程)不同調用方式和不同性能依賴的吞吐量和性能指標,可以看出:
同樣耗時依賴條件下,hystrix會占用更多的cpu資源,但是並不顯著,並且當耗時增加時該影響持續減小(由於壓測介面無任何計算邏輯因此整體cpu使用很低,推測實際服務邏輯耗費CPU較多時hystrix的性能影響更不明顯,有待生產環境驗證)。
相同的壓測線程(hystrix處理線程也是10)下依賴耗時以及與之對應的平均耗時avg直接影響了介面的吞吐量(rps,每秒請求數)。觀察該規律可以得到公式:threads / avg(s) = rps,下麵舉例:
avg=320時,10 / 0.32 = 31.25,觀察用例7,8分別得到原生30.2和hystrix的30.3,基本吻合。
avg=80時,10 / 0.08 = 125,觀察用例5,6分別得到原生120.4和hystrix的120.1,有所損耗後吻合。
avg=20時,10 / 0.02 = 500,觀察用例3,4分別得到原生456.6和hystrix的454.4,損耗增加。
avg=5時,10 / 0.005 = 2000,觀察用例1,2分別得到原生1536.4和hystrix的1521.4,損耗較大。
其他信息:從上面數據也可以看出當rps增加到較高時線程調度本身帶來的損耗增加顯著,CPU使用率也顯著上升,即線程調度壓力開始顯著增加,無論是否使用hystrix這都是無法避免。hystrix在相同耗時對比中增加部分cpu使用率,對max指標有所影響,個別數據下對tp999也有所影響,但是影響都比較小。
後面三組測試用例則繼續提高壓測線程,由於hystrix預設配置10個線程,因此當壓測超過10個線程時,多出來的請求則會處理不過來,體現為線程池滿後直接拒絕,快速返回失敗,同時快速返回後壓測端又會立刻請求,結果就是rps迅速上升同時成功率急速下降,線程池正常處理的請求則未受影響,用例9體現了這一現象(服務端監控avg=320而客戶端由於大量1ms的快速失敗返回使avg=14)。
用例10和11是原生調用,我們繼續提高壓測線程到200和201,以期測試JSF的200線程池,得到結果符合預期,即JSF線程被打滿後無法處理額外的請求,與用例9表現相似,但是臨界值從10線程到200線程,更多的線程帶來了更多吞吐量。還有一點不同的細節在於,hystrix線程滿後返回異常時可以觸發我們的UMP監控,捕捉到成功率下降,但是JSF線程池滿後,直接拒絕請求,服務端無法監控到這些失敗,只有調用端能得到成功率下降的信息。
結論
通過上面壓測數據解析,我們可以對開始的問題進行解答。
額外的線程池是否有太大的性能開銷?
上述測試中hystrix對性能損耗並不大,不管是CPU使用率的增加已經性能指標的影響都不明顯,但是由於測試用例的局限性,不能說明所有情況,但我認為達到了到生產環境小範圍使用的條件,可以通過繼續積累使用經驗解答該問題。
The Netflix API processes 10+ billion HystrixCommand executions per day using thread isolation.
Each API instance has 40+ thread-pools with 5-20 threads in each (most are set to 10).
線程池大小設置多少合理?
我們在測試中得到了公式:threads / avg(s) = rps,實際上hystrix的文檔中也有一段類似的描述:
requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room
30 rps * 0.2 second = 6 + breaking room = 10 threads
初看這段描述時難以理解,但是通過我們上面的壓測數據和公式可以明瞭,它將avg替換為了tp99,同時再增加了更多餘量,以期儘量避免正常流量增長和依賴波動導致線程池被打滿的情況。
舉一個實際例子,小金庫當前併發量最大的介面A,在去年雙十一壓測中達到了22.6W的RPS(是平時峰值10倍),一共有201台實例,單實例RPS=1124,tp99=6ms(avg=2ms),以此計算 1124 * 0.006 = 6.7,因此增加餘量到10(或15)即可滿足需求。
新問題,線程池滿了怎麼辦?
在上面測試數據解析中,我們發現由於hystrix為每個依賴嚴格限制了一個小的線程池,當線程池滿了後拒絕服務似乎影響很大。根據我們的公式threads = rps * avg(s),當流量過高時或依賴耗時增加過多時都會觸發線程池打滿。首先針對流量過高我們可以通過監控報警(主動增加線程數,可以動態配置生效) + 提前預設足夠的餘量解決。其次針對依賴耗時增加過多的問題,前面的做法也能部分解決該問題,但是回歸起點來說,某個依賴突然變得非常慢,以至於打滿JSF線程池造成應用整體不可用,這本來就是我們要用hystrix解決的問題,使用hystrix後故障依賴的調用快速失敗,同時失敗率積累到閾值後斷路器熔斷降級,在該依賴恢復後自動關閉斷路器,恢復對其調用 。