性能測試之線上引流測試--讓性能測試更真實更豐富

爲何要作引流測試

目前爲止大部分的測試是在測試環境下，經過模擬用戶的行爲來對系統進行驗證，包括功能以及性能。在這個過程當中，你可能會遇到如下問題: 

• 用戶訪問行爲比較複雜，模擬很難和用戶行爲一致，模擬不夠真實;

• 線下模擬場景有限，會出現業務覆蓋不全的狀況。
  引流測試就是爲了解決以上問題，經過把線上的真實流量複製到線下環境，解決測試環境模擬不夠真實，或覆蓋不夠全面的問題。

引流的作法

目前很多公司對引流測試進行了實踐，主要有如下4種引流方式：

以上幾種辦法各有利弊，有的是須要本身開發相應的工具來支持。在作URS產品性能測試過程當中，考慮到都是HTTP類型的請求，且大部分的請求爲讀請求，使用tcpcopy工具能夠知足要求，且成本比較低。在介紹基於tcpcopy的引流測試在項目中怎麼應用以前，咱們先來介紹下tcpcopy這個工具。

tcpcopy介紹

tcpcopy是一種請求複製(基於tcp的packets)工具，其應用領域較廣。tcpcopy主要有以下功能： 

• 分佈式壓力測試工具，利用在線數據，能夠測試系統可以承受的壓力大小,同時提早發現一些bug;

• 對於後端的短鏈接，請求丟失率很是低(1/10萬)，能夠應用於熱備份;

• 普通上線測試，能夠發現新系統是否穩定，提早發現上線過程當中會出現的諸多問題，讓開發者有信心上線;

• 對比試驗，一樣請求，針對不一樣或不一樣版本程序，能夠作性能對比等試驗;

• 利用級聯tcpcopy，構造無限在線壓力，知足中小網站壓力測試要求。

圖1 tcpcopy工具流量複製過程

1. 在線服務器啓動tcpcopy進程，在IP層捕獲數據包，經過數據鏈路層發包;

2. 複製的包到了被測試服務器，通過協議棧的處理，到達應用進程，進程處理完，響應的包經過路由轉發給輔助服務器;

3. 輔助服務器捕獲到路由過來的響應包，去掉包的body，返回給在線服務器。

整個過程是一個閉環，引流的過程不會干擾用戶的請求，複製的請求的響應，也不會返回給用戶。

URS引流測試實踐

接下來說述下tcpcopy是怎麼在URS這個產品中運用起來的，經過下面的案例來分享下整個引流測試的過程。

案例：本人經歷過一個項目主庫的性能驗證，優化及替換

背景介紹：

該產品的線上數據庫服務器年限比較長，配置比較老，另外數據庫服務器在瞬時訪問量比較大的時候，會出現性能降低的問題。爲了提升數據庫服務器的穩定性，以及對數據庫的參數進行一些優化，產品方計劃採用新的數據庫服務器來代替線上服務器，且在上線先進行一輪優化，保證新的數據庫知足目前的性能需求的狀況下，再替換掉線上的數據庫。

測試的難點

1. 新數據庫的數據量基本要和線上是一致的，不然測試的意義不大；

2. 僅僅依靠線下的請求模擬是不夠的，須要線上真實的流量來驗證；

3. 須要提供突發流量，高於線上的流量等場景來驗證新的數據庫服務器是否可以處理突發狀況。、

測試方法

利用tcpcopy工具，搭建引流測試環境，利用線上真實流量，倍數流量，突發流量，驗證新的163主庫的性能，並與DBA協做，進行參數優化和驗證。

測試成果

經過複製真實流量，有效驗證了現有數據庫的性能，而且經過調整流量，對數據庫形成多樣的負載，進而對數據庫進行參數優化，保證了數據庫的性能和穩定性

引流測試方案

爲確保引流測試順利實施，先制定一個詳細的方案，方案主要包括業務選取，環境搭建，結果分析和驗證等，接下來逐一介紹這些部分。

測試環境搭建

須要先根據線上環境部署架構來肯定咱們的引流測試環境應該搭建成什麼樣子。下面爲引流環境架構示意圖。先簡單介紹下：

環境部署以下：

圖2 測試環境部署

1. 線上Nginx服務器上安裝部署tcpcopy，負責把指定的流量複製到測試環境；

2. 引流環境的數據庫經過導入線上的數據庫的備份初始化數據，同時經過作成線上的備庫，保持和線上數據庫的同步。每次要開展引流測試的時候，先剝離出來，作完測試以後再和線上數據庫進行同步；

3. 爲了不引流操做更新部分緩存，致使弄髒了線上的緩存數據，同時爲了控制穿透到數據庫的量，搭建了單獨的緩存服務器集羣；

4. 搭建mock服務器，把短信，郵件，將軍令等服務都mock掉，避免觸發到這些操做，影響用戶，另外也能夠經過在前端Nginx進行請求過濾，來屏蔽可能觸發這些操做的請求。

引流業務選取及過濾

環境搭建好之後，須要肯定複製哪些請求到測試環境，如下三類請求是不建議引流的， 須要屏蔽掉。

1. 沒法處理的請求
   測試環境由於缺乏數據或者缺乏外圍系統等，致使這類請求在測試環境執行會報錯，所以須要過濾掉。

2. 連續相關的請求，或者有狀態的請求
   連續相關的請求由於存在狀態，請求之間的數據有傳遞，致使複製過去的話，業務處理會報錯，也須要過濾掉。舉個簡單的例子，好比登陸操做，服務端可能會須要填寫驗證碼，複製過來的請求的驗證碼和原始的請求是不同的。若是登陸操做也複製過去了，驗證碼是無效的。

3. 寫請求
   寫請求會新增數據，且通常寫請求的量比較小，請求大都有狀態，不是很適合引流。若是寫請求的影響很小，也須要進行寫請求的測試，也能夠進行復制，可是要特別注意，不要弄髒線上環境的數據，或者對線上的業務有影響。

請求過濾能夠經過如下方式實現：

1. Nginx配置Location進行過濾

   location ~* ^/services/(otplogin|onlyotplogin|qrcodeotpauth|onlyotplogin|ticketotpauth) { expires -1; return 200 'request mocked\n'; }

   把須要屏蔽的請求，直接返回200。這裏要通過仔細篩選。上面的配置只是一個示例，實際項目能夠按照規則來過濾。 

2. 搭建mock服務器進行過濾 請求的處理過程當中，若是會調用第三方系統，這個時候能夠搭建mock服務進行屏蔽。

引流測試執行

環境準備好以後，就能夠執行引流測試了，引流測試過程會包含如下步驟：

配置檢查

1. Nginx的Location配置，避免複製了不合適的請求到測試環境； 

2. 應用配置是否正確，一切會影響線上用戶的配置都須要調整； 

3. 緩存服務器的配置是否正確，確認使用的是測試環境的實例，且能正常訪問； 

4. 數據庫的配置是否正確，確認使用的是測試數據庫，且能正常訪問； 

5. Mock服務器是否正常，服務的返回是否正常等； 

6. 以上檢查完成後，在測試的Nginx上利用curl工具手動發送請求驗證環境。

啓動輔助服務器intercept

1. 啓動命令

   sudo ./bin/intercept  -i 網卡  -F 'tcp and src host ${測試Nginx IP地址}  and src port  ${測試Nginx端口} ' -p  ${intercept的監聽端口}  -d

   能夠不指定監聽端口使用默認的36524，若是要啓動多個實例，端口是必須指定。啓動後經過netstat –an | grep 監聽端口，檢查端口是否正常。

2. 檢查error_intercept.log日誌文件 檢查文件有沒error和fatal級別的錯誤信息。

3. 綁定在不一樣的CPU上
   若是intercept進程的CPU使用率比較高，須要啓動多個intercept而且綁定在不一樣CPU上，能夠經過執行 taskset -cp ${cpu $pid來設定，其中

   cpu爲CPU的編號， 

   pid爲intercept的進程號。

    

配置路由並驗證

在測試環境的Nginx上增長默認網關，設置爲intercept的地址： 命令：route add default gw ${intercept的IP} 設置好路由信息後，能夠找一臺測試機器，telnet測試環境Nginx的服務端口80，若是可以創建鏈接，說明路由信息沒生效，測試環境Nginx服務器的包沒有轉發給輔助服務器，能夠找SA的同事幫忙協助，肯定路由要怎麼配置。

啓動tcpcopy

在線上Nginx服務器，啓動tcpcopy命令：

sudo bin/tcpcopy -F 'dst port ${線上nginx端口} and dst host ${線上nginx IP} '  -i  網卡 –x  ${線上nginx端口} -${測試環境nginx的IP}:{測試環境nginx端口} -s ${intercept的IP} -n 1 -d

啓動後，檢查error_tcpcopy.log日誌文件有無error和fatal級別的錯誤。

請求驗證

對線上nginx和測試nginx的日誌進行對比，檢查請求是否是已經複製到測試環境，請求返回的大小和狀態碼等是否正常，同時，檢查應用服務器是否有錯誤日誌。若是有錯誤，影響到了線上環境，或者錯誤不少，先中止引流，解決報錯。 

系統監控

引流過程當中，能夠利用哨兵系統對線上Nginx服務器，測試服務器的系統資源，應用服務器、數據庫進行性能監控。

調整流量

引流過程當中，會根據測試環境的負載，調整複製的流量，經過修改tcpcopy的啓動參數來調整。-n 設置複製的倍數，-r 能夠設置複製的比例(1<r<100)。 

引流測試結果分析

前面的章節介紹了引流的方案和執行過程。引流開始後，咱們怎麼去分析系統當前的性能呢？在數據庫的性能驗證的案例中，咱們一方面要知道當前的業務負載狀況，同時也須要知道應用和數據庫的各項資源的使用狀況。

如何監控業務指標

業務性能指標，主要是經過對nginx的日誌進行分析來完成，分析可以監控到全部請求，以及單個請求的TPS，錯誤，平均響應時間，最大響應時間4個重要的指標。 

圖3 業務指標監控

例如在圖3中，能夠實時監控到***login這個接口的TPS，ERRORS，AVG_RT，MAX_RT四個指標。

如何監控數據庫

數據庫能夠經過在相似於zabbix系統進行配置性能監控。引流過程當中，能夠實時監控數據庫的各項性能指標，觀察是否有異常，進而調整複製的流量。 系統資源指標：CPU，內存，網絡，磁盤等常規資源監控指標。 數據庫性能指標：數據庫各內存池使用率和命中率，Average active session，Database Time Ratio， 會話鏈接數，IO讀寫吞吐量，IO讀寫請求次數，執行次數，資源使用率等。
經過監控這些指標，定位數據庫的性能瓶頸，讓DBA進行優化和調整，再複測。找出最佳的配置。這些性能指標，咱們能夠經過哨兵系統來實時監控。 

例如，咱們在引流過程當中監控到的鏈接數，活躍的會話，內存池的使用狀況如圖4所示：

圖4 內存池大小的實時監控

圖4是對內存池大小的實時監控，能夠監控到PGA，buffer_cache內存，共享池內存，large_pool內存，java_pool內存的實時使用量。

圖5 數據庫的會話鏈接數的實時監控

案例結果分析

引流過程當中，經過調整流量，而且實時監控業務性能指標和數據庫的各項指標是否正常。在業務性能指標，特別是響應時間在合理的範圍內，數據庫的各項性能指標也在合理的範圍內，獲得業務的TPS和數據庫的負載狀況，做爲數據庫性能評估的結果。

例如，在數據庫的引流測試中，經過線上多臺Nginx複製5倍的流量到引流環境，同時disable掉部分緩存，請求直接穿透到數據庫，在這樣的負載下，獲得的數據庫的性能數據以下:

 

鏈接數	QPS	sqlnet MB	largepool	sharepool	load	CPU	CS	Net IO
9600	3.5W	5MB	25G	15G 30%	4	sys 25% user15%	30K/s	10MB/S

 

 

本文章爲做者原創

🈲禁止🈲

其餘公衆帳號轉載，如有轉載，請標明出處