記一次Spring Cloud壓力測試

前言

       公司打算舉辦一場活動,現場參與活動人數比較多。針對於可能訪問比較密集的接口進行壓力測試。使用jmeter進行測試,請求併發稍微多些,系統就會掛起。數據庫

  針對壓力測試出現的問題,由於併發超過1秒鐘100筆就會出現問題,Spring Cloud做爲一個成熟的框架,不多是框架不支持。因此首先想到的是配置上須要進行調優。緩存

一、Spring Cloud配置調優

  請求從jmeter發出後,須要經過Zuul網關,而後到Spring Cloud微服務端。因此,整個調優方向分爲兩個地方:微服務端和zuul網關。架構

1.二、微服務應用

  當jmeter調整到每秒鐘70個併發請求時,服務應用端的日誌中出現了不少hystrix回滾,而且有不少HystrixRuntimeException。併發

com.netflix.hystrix.exception.HystrixRuntimeException ... could not be queued for execution...

  緣由:Hystrix請求線程池缺省爲最大10個線程,在大量請求下,很容易超過這個數值,致使拋出異常。框架

  解決方法:在配置文件中修改線程池中的coreSize(properties方式的配置文件)分佈式

hystrix.threadpool.default.coreSize=500

  配置上測試後,客戶端再也不出現hystrix的異常了,可是併發請求數進一步提升到100以上後,依然會沒法響應請求。微服務

1.三、zuul網關

  因爲網關也配置使用了Hystrix,在併發請求過大時,也會拋出異常:高併發

com.netflix.hystrix.exception.HystrixRuntimeException: ggx-test short-circuited and no fallback available

  顯示的異常時,具體的ggx-test服務系統短路而且沒有熔斷可用,但ggx-test系統還正在運行,因此問題出如今zuul網關上。性能

  ① zuul內部路由能夠理解爲使用一個線程池去發送路由請求,因此咱們也須要擴大這個線程池的容量。測試

zuul.host.maxTotalConnections=1000
zuul.host.maxPerRouteConnections=1000

  ② zuul使用Hystrix,而Hystrix有隔離策略: THREAD 以及 SEMAPHORE ,默認是 SEMAPHORE ,默認大小是100。請求的併發線程超過100就會報錯。

zuul.semaphore.max-semaphores=5000

  配置完上述配置後,從新進行測試,在日誌中不會出現錯誤了,可是併發請求超過100/S時,系統掛起,再也不響應請求。因而,排查各類可能後,想到了多是數據庫鏈接池的問題。

二、數據庫鏈接池

  咱們系統使用數據庫鏈接池是c3p0,最大的數據庫配置的鏈接數爲30個,嘗試將數據庫最大鏈接數修改到100時,使用jmeter測試,併發請求可以稍微提升些。這樣可以定位到問題就在數據庫鏈接池上。

  目前市場上主流的開源數據庫鏈接池有:C3P0,DBCP,Druid,HikariCp。其中C3P0和DBCP是出現的比較早的數據庫鏈接,比較穩定,在低併發的狀況下,總體表現還不錯,可是在高併發下,響應時間變長,性能不好,甚至於死鎖。Druid是阿里巴巴開源的高性能數據庫鏈接池,雖然性能不及HikariCp,可是它提供的各類維度的統計分析的功能,在國內市場流行度很高。

  相關的數據庫鏈接池對比:

 

C3P0/DBCP

Druid

hikariCP

應用

主要在Hibernate

 各大主流平臺

起源於boneCP

性能

較差

很強

線程池容器

Blocking Queue

List Reentrantlock

 

  綜合,Druid性能比較優異,網上文檔資料很健全,加上可視化的統計分析很適合咱們解決當前問題。咱們將數據庫鏈接池從C3P0換到了Druid。

三、總結

  通過上面優化,壓力測試達到了預期,jmeter每秒鐘發送1000個併發請求,系統可以在預期時間內順利返回響應結果。雖然不是很高,可是應對咱們當前業務需求是足夠的。沒有最優的架構,只有最合適的架構,一切系統設計原則都要以解決業務問題爲最終目標,脫離實際業務的技術情懷架構每每會給系統帶入大坑。固然這並不能影響咱們對技術的追求,在碰到併發請求大的狀況下,有幾個維度能夠進行嘗試優化:首先就是限流,將請求攔截下來,不要對系統形成太大壓力;其次使用各類緩存,對於不須要訪問數據庫的資源緩存起來,提升響應速度,減小數據庫壓力;而後使用分佈式部署,使用集羣替代單機;還有優化接口對SQL進行調優等等。

相關文章
相關標籤/搜索