性能測試實踐分享

性能測試實踐分享

性能點：營銷招商活動，提交報名

 

前言：

    如下是我在項目中完成的另外一次性能測試實踐，對性能測試還處於摸索階段，若是有不許確的地方歡迎指點。

1、簡介

批量提交報名，libra2manager應用處理請求，調用libra2center服務進行相關商品和賣家信息的判斷，調用qc服務進行賣家商品資質判斷是否可報名、成功後插入到數據庫。

系統依賴圖

2、指望值的評估

RT ：

按照統一標準制定爲300ms

TPS ：

賣家端應用libramanager平時一天的總pv量爲30w；指望pv=總pv量*5 = 150w （考慮平時的小型促銷*5，賣家開放後須要從新開發並從新考慮性能）

根據計算公式

每秒**平均值 =( (總PV量*80%)/(24*60*60*40%))/服務器數量（4） =  pv/s   = 8

每秒**峯值 = (((總PV量*80%)/(24*60*60*40%))*1.6) /服務器數量（4）=  pv/s   = 15 （平時最大的壓力）

按照去年雙12的場景，增長線上機器的狀況下，預期TPS是50 （開發提供的數據），則將這次TPS設置爲50

3、Checklist

1、指望值評估

2、環境搭建：應用、數據庫

3、HTTP腳本（HSF腳本）

4、性能環境數據準備

5、功能是否已穩定

4、實施壓測

壓測結果

TPS 和 RT 都不知足指望

緣由分析：CPU、JVM、load

應用：libra2manager、libra2center、qc、DB

應用libra2manager、libra2center、qc的cpu、jvm等值都正常，再看DB的表現

緣由定位：DB鏈接過多，一次批量提交3條報名的操做大約有21次select、3次update、1次的delete、1次insert

  (天機系統中查看)

5、緣由分解

緣由分解-爬代碼，看看爲何有這麼屢次的數據庫操做，如下是調用的會操做到數據庫的接口

數據庫操做：>20 ，分析結論：

1、屢次查詢contentDo，blockDo，有優化空間

2、save和submit報名記錄前的查詢目前是3條記錄3次查詢可優化成一次查詢

6、調優

調優勢

1、較多的contentDo查詢，改用讀取tair的方式（這個問題應該是能夠規避的，因爲多個模塊由不一樣開發負責，開發們缺少溝通，缺少總體的統籌）

2、批量報名saveApplication方法和submitApplication方法前的查詢，改爲一次查詢

3、ContentBlockQualiRootService查詢獲得的QualiDo，做爲ApplicationAcessService接口的入參，減小查詢一次QualiDo

調優結果

結論

一、調優後，批量提交三條報名記錄，對數據庫操做約11次，總體TPS提高約2.5倍。

二、單submitResult方法種就有3~4次的數據庫操做，這塊功能經評審不是很是重要，決定後續增長開關，系統壓力較大時，屏蔽該功能，進一步減小對數據庫操做

性能點：活動列表查詢

前言：

    如下是我在項目中完成的一次性能測試實踐，對性能測試還處於摸索階段，若是有不許確的地方歡迎指點。

1、簡要介紹

    賣家進入淘營銷系統，查看當前可報名的全部營銷活動。前臺應用libra2manager首先從vsearch讀取當前在報名進行中的全部活動，qc讀取 這些活動所需判斷的全部指標項後獲取賣家對應的指標值，根據指標項要求和賣傢俱體指標值判斷賣家可報名的全部活動，展示在可報名活動列表中

    qc首先在tair中讀取賣家指標值，若tair中不存在該指標值，則從對應的datasource中讀取

    系統依賴圖

2、指望值的制定

¨ RT ：

     全部活動列表按照統一標準制定爲300ms；可報名列表業務調用的邏輯複雜度，再參照去年對列表的壓測結果（分頁有3s）和指望值（500ms），設置爲500ms

¨ TPS ：

      賣家端應用libramanager平時一天的總pv量爲30w；指望pv=總pv量*5 = 150w （考慮平時的小型促銷*5，賣家開放後須要從新開發並從新考慮性能）

根據計算公式

每秒**平均值 =( (總PV量*80%)/(24*60*60*40%))/服務器數量（4） =  pv/s   = 8

每秒**峯值 = (((總PV量*80%)/(24*60*60*40%))*1.6) /服務器數量（4）=  pv/s   = 15

3、系統設計階段

qc的指標讀取validate，如下四點是開發所進行的性能考慮

1. 提供批量驗證接口，避免屢次hsf調用。

2. 將資質數據讀取方式從原有的懶加載改成預加載。合併多個資質樹的資質，一次讀取。

3. 並行數據讀取。資質數據涉及多個系統（多個HSF調用），將多個HSF調用從串行改成並行

4. 並行驗證。批量驗證時採用並行的方式驗證。

總結下來就是

一、a、b、c：並行、tair

二、d、e、f：一次讀取

三、屢次調用變一次調用

其實大多數read方式的功能點均可以按以上三個方向去考慮性能問題，化串行爲並行，化屢次調用爲一次調用，讀取慢就考慮採用tair。

測試改進

原讀取方式：合併指標項一次讀取數據源a、b、c中對應所需的d、e、f

改進點：合併指標項一次讀取數據源a、b、c中全部的指標值

舉例，請求1須要數據源a中的指標d、e和數據源b中指標f；原讀取方式是並行將a、b中的d、e、f讀取出來；改進後的讀取方式是並行將a、b中的d、e、f、g、h...都讀取過來；它的性能提高將體如今下一次須要讀取指標g、h...的請求N中

4、壓測前的checklist

1、指望值評估：TPS、RT

2、性能環境搭建

3、HTTP腳本（HSF腳本）

4、性能環境數據準備

5、功能是否已穩定

5、壓測

     第一次壓測結果，咱們指望結果能更好

場景名	併發用戶數	事務名	性能指標		事務統計
			TPS	RT(ms)	執行事務數	失敗事務數	失敗率
淘營銷-list	14	canActions	22.961	506.519	82427	0	0%
		allActions	22.963	104.37	82436	0	0%
淘營銷-list	25	canActions	23.549	818.815	85010	0	0%
		allActions	23.549	193.079	85010	0	0%

RT太高！

應用：Libra2manager->qc->Vsearch

分析：CPU、JVM、load

Libra2manager和qc的cpu、jvm都正常，Vsearch機器達到75左右，再經過profile打點判斷RT消耗

緣由定位：Vsearch數據讀取耗時佔比>80%

這 裏要提一個點，系統在設計過程當中，考慮到性能問題，設置一次從vsearch讀取的活動量爲1024，獲取第一批活動後即合併資質計算是否可報名，同時獲 取第二批1024個活動，並行讀取和驗證。daily上目前是3100左右個報名進行中的活動，因此會有三次vsearch讀取。

6、調優

    從結果上來看，vsearch讀取耗時佔比>80%的狀況下，設計讀取三次vsearch結果和qc驗證並行可能不是最合理的。所以，調整一次vsearch讀取的值驗證性能表現

調優過程記錄，將一次查詢量上限設置爲4000時性能表現最優。

¨

¨ 結論

1、當前活動量，一次將全部活動所有查詢性能最好

2、當前線上處於報名中狀態的活動爲1943個，預計很長時間內將穩定在3000內，則將一次查詢量數字肯定設置爲3000

7、最終壓測結果

場景名	併發用戶數	事務名		性能指標				事務統計
				TPS指望值	TPS	RT指望值（ms）	RT(ms)	執行事務數	失敗事務數	失敗率
混合場景：淘營銷list	14	canActions	可報名活動	15	25.717	500	408.84	92322	0	0%
		allActions	全部活動	15	25.72	300	139.184	92333	0	0%