一種基于Tsung負載測試的應用與實現

楊 旭

(中央宣傳部電影數字節目管理中心,北京 100866)

1 項目背景

在計算機化、全球互聯化發展的今天,人們足不出戶可以更直接的感受視頻、電影、科技、購物的快感,享受互聯網帶來的紅利。但移動互聯網時代的到來也帶來了新的挑戰,首先就是用戶覆蓋面的不斷擴大與用戶訪問量的突增。本文基于農村電影數字節目交易平臺,以優化該平臺的服務負載性能為目的,采用一種基于Tsung分布式負載集群測試方式對該平臺的web 應用服務性能進行負載測試。該應用的實現是優化升級web應用服務器負載性能的主要依據之一,通過負載壓力測試可以檢測出系統的運行瓶頸,也為系統在生產環境下運行做好評估和預案,對業務系統的風險防控有重要作用。

1.1 測試目的

平臺系統的測試主要包括平臺的功能性測試、非功能性測試。功能性測試主要在單元測試、集成測試階段進行;非功能性測試在集成階段測試,主要包括有負載測試、安全階段測試、容量結果測試、兼容性性能測試等測試過程。

負載測試(又稱壓力測試),是對web平臺整體執行能力的一種測試,其主要是需要在大量數量、高頻率等方式或其突發資源使用率的方式下進行的負載測試,以找出web應用服務器對異常情況的處理能力及抵抗能力的瓶頸。

異常情況,是指模擬用戶訪問數量瞬間達到訪問峰值,CPU 占用、內存消耗瞬間增加,處理大量數據,長時間運行等情況。壓力測試是迫使web應用服務在這種異常情況下運行,但負載測試不可能模擬所有業務流程,所以要確定關鍵的業務流程,結合業務流程及需求編寫測試用例。

負載測試的加載方式分為一次性加載、遞增加載、高低突變加載、隨機加載四種方式。借助遞增加載和一次性加載方式可以容易獲得web系統的性能拐點,即性能瓶頸點。

本文采用了Tsung軟件模擬大量的用戶數據輸入量,以檢測系統web應用服務器處理大量用戶訪問的處理能力及性能瓶頸。本文結合本平臺的實際應用需求,采用了一次性加載和遞增加載結合的方式進行壓力測試。在系統測試過程中引入了分布式集群壓力測試方案,即利用負載均衡把同一個業務分布在多個服務器上,把模擬客戶端業務分拆成多個子業務分布式部署在不同的測試服務器上。

分布式模式是以縮短單個任務的執行時間來提升效率的,而集群則是通過提高單位時間內執行的任務數來提升效率。就比如現在主流平臺愛奇藝、淘寶、新浪微博等訪問量大的互聯網平臺,都采用了集群模式,前面放一個均衡服務器,后面幾臺服務器完成同一業務,如果有業務訪問的時候,監測服務器的負載,平衡每臺負載量,即使有一臺服務器宕機,其他服務器也能補充上來。因此本文待測web服務端采用集群部署模式,壓力測試采用分布式模式實現。

1.2 性能指標

衡量一個軟件系統的常見性能指標有:吞吐率、響應時間、資源占用率、并發用戶數等指標值。

(1)吞吐率:軟件web服務器并發處理能力的量化描述,單位是請求數/秒 (即reqs/s),指的是在某個并發用戶數下單位時間內處理的請求數。某個并發用戶數下單位時間內能處理的最大請求數,稱之為最大吞吐率。吞吐率和并發用戶數相關,不同的并發用戶數下,吞吐率一般是不同的,這個數值表示當前機器的整體性能,值越大越好。

(2)最大并發用戶數:表示會話 (Session)開始且尚未結束,并且已建立連接的最大用戶數。該指標反映了系統在高并發用戶下的處理能力。

(3)會話 (Session)響應時間:會話響應時間是用戶體驗系統最直觀的感受,表示每個用戶會話持續時間,是服務器響應時間、網絡響應時間和客戶端響應時間的總和。

(4)服務器資源占用率:包括常見的機器的CPU 使用率、內存使用率、磁盤占用率、網絡I/O占用率等。

這個是在簡單 (單一訪問鏈接)的情況下,可通過日吞吐量指標來評價一個系統的性能,吞吐量越大系統性能越穩定,具體公式如下:

日吞吐量=吞吐率×24×3600

當系統隨著用戶的并發數的增加,平均響應時間也在增加,每秒處理的請求也就增加,用戶等待請求的時間也會變長,會造成吞吐率的下降,因此一個系統的吞吐量要綜合考慮用戶并發、吞吐率、響應時間、硬件服務器的資源使用等綜合因素。

1.3 測試軟件選擇

隨著越來越多的用戶開始使用該平臺,為滿足平臺高訪問量的需求,需要選用支持分布式、高并發的壓力測試軟件。目前常用的壓力測試軟件有Load Runner、Jmeter、Tsung等軟件.

Tsung是基于Erlang開發的,是開源的、支持多協議、支持分布式的負載測試軟件。Jmeter的架構和Loadrunner原理一樣,都是通過中間代理,監控和收集并發客戶端發出的指令,把他們生成腳本,再發送到應用服務器,再監控服務器反饋結果的一個過程。Jmeter安裝簡單,和Tsung一樣都屬于開源軟件,但是沒有IP欺騙功能,不符合本文采用的模擬真實用戶訪問的需求。Load Runner雖然有強大的結果分析能力和UI界面,但是屬于付費、重量級軟件,在自由度上有限,擴展性較差、不夠靈活。

下面對Tsung和Jmeter兩款開源的測試軟件進行比較,如表1所示。

表1 Tsung和Jmeter比較表

由以上比較得出,Tsung和Jmeter均屬于輕量級,Jmeter支持Windows,而Tsung在支持操作系統上,包括Windows和Linux下Ubuntu、Cent OS不同Linux的版本。在腳本錄制方面,Jmeter 用戶改寫復雜,而Tsung更靈活,手工修改錄制腳本更簡潔方便,也支持協議多樣,滿足對現有平臺的web應用服務器的測試需求。

2 測試方案

隨著百姓對農村公益電影的關注度越來越高,平臺業務量需求將不斷地增加。本文以提高平臺負載性能、支持大量用戶訪問的需求為目的,利用壓力測試軟件對平臺系統進行負載實驗,根據實驗測試結果有針對性的指導平臺進行優化升級。

首先建立測試環境,配置壓力測試機器為4臺裝有Cent OS7操作系統的服務器,內存128GB,分別安裝Tsung1.7.0 軟件,錄制測試腳本并根據需求修改運行腳本。分別采用單點和分布式兩種測試方案,利用單個客戶端Client和多個客戶端Clients分布式兩種方式對web應用服務器進行負載壓力測試。

單點測試策略:用單點Client對單臺web應用服務器進行負載測試,檢查該服務器的性能,考察當前軟硬件環境下系統所能承受的最大負載瓶頸。

分布式測試策略:優化調整Cent OS 操作系統的參數,并調整增加負載均衡配置,配置Tsung分布式方案。

2.1 單點測試策略

2.1.1測試用例選擇

本文模擬平臺上業務用戶的使用習慣和業務操作頻率,模擬院線用戶、放映隊用戶、普通用戶等用戶的常規操作的使用情況,觀察在Tsung負載壓力下平臺的web服務器端系統的負載值,具體方式分兩個階段測試:第一階段采用一次性加壓的測試方式并有10分鐘處理間隔時間;第二階段每隔10秒鐘逐步加載壓力,詳細信息如表2所示。

表2 測試用例表

100 4mn21sec 795 Max:98req/s 200 3mn19sec 1260 Max:125req/s 300 6mn11sec 1200 Max:70req/s 400 9mn56sec 1569 Max:99req/s 500 11min57sec 2082 Max:79req/s 1000——--

2.1.2用例配置

根據測試計劃配置Tsung 的參數,配置測試tsung.xml腳本文件,以并發50用戶為例:arrivalrate="50"unit="second",即以秒為單位,每秒模擬并發50個用戶數,如此依次配置模擬產生的并發數。

2.1.3測試結果

測試結果以報表方式提供,以下分別為每秒并發25個、100個、500個的吞吐率的測試結果為示例,如圖1、2、3所示。

圖1 并發數為25每秒結果圖

圖2 并發100每秒結果圖

圖3 并發500每秒結果圖

本輪測試主要目的是找出單臺web服務器的負載瓶頸,并加以改進。從單點測試結果可以看出,在測試過程中出現未達到瓶頸、達到瓶頸、超過瓶頸三種情況:

(1)隨著并發用戶數的增加,單臺壓力測試并發數在200以下時,系統吞吐量會逐漸增加,此時響應時間會較快,此時系統未達到瓶頸。

(2)當單臺壓力測試數超500并發后,隨著并發用戶數的增加,系統吞吐量不再會增加,此時響應時間會開始變長,首頁頁面運行緩慢,CPU 飆升100%以上或更高,吞吐率在200～300r/sec之間,此時系統達到瓶頸。

(3)最大并發用戶數在1000 之后很難繼續增加,系統已超過瓶頸,隨著并發用戶數的增加,系統吞吐量出現下降,此時響應時間會逐漸拉長,甚至無響應。此時監測網卡帶寬如圖4所示,網卡帶寬超過500M,圖片帶寬占用大,經過對結果分析對比,從機器性能、系統吞吐量等性能出發,當單機用戶模擬用戶數達到1000并發量時單機系統達到瓶頸。

圖4 網卡帶寬監測圖

本文為解決此瓶頸提出改進方案并做分布式負載測試策略,主要從以下幾個方面改進:(1)調整本機參數,修改機器的limits參數,網絡Net參數等基本參數;(2)增加負載均衡配置,可增加多臺web應用服務器,如可配置Nginx軟件均衡或硬件均衡等措施;(3)調整網絡帶寬,如從圖片壓縮算法、分布式存儲等算法方面來減少帶寬壓力。

2.2 分布式測試策略

隨著測試的進行,本文在單點測試中發現,當壓力測試機器調整操作系統的機器參數后,系統模擬并發數達到1000之后系統出現明顯瓶頸,因此單點測試方式存在其瓶頸點。

分布式測試策略可以讓多臺機器并發測試,單臺在理論狀態下由于硬件限制最多模擬不超過65535個用戶數,而要模擬超百萬的用戶數則需要用分布式策略解決。

2.2.1部署分布式壓力測試環境

分布式測試策略由4臺web應用服務器組成的集群、1臺負載均衡服務器、4 臺Tsung客戶端組成,本文根據項目需求配置四臺Clients,組成分布式Tsung壓測服務端。表3為Tsung測試環境集群配置表,圖5為Tsung分布式壓力測試及集群架構圖。

表3 Tsung測試環境集群配置表

圖5 Tsung分布式壓力測試及集群架構圖

2.2.2負載均衡配置

負載均衡根據負載均衡算法將客戶端請求分發給后端服務器,Nginx 是一款廣泛應用的高性能Http服務器,能滿足上萬級別的請求調度,有多種負載均衡模塊算法可配置。Nginx目前提供的負載均衡模塊主要有:加權輪詢模塊 (round_robin),可均分請求,是默認的Http 負載均衡算法,集成在框架中;IP 哈希模塊 (ip_hash),可保持會話;最少連接數模塊(least_conn),可均分連接。

表4 Nginx均衡算法模塊比較表

基于上述各個負載模式的特征,根據本文的需求,需要保持會話的測試同時能測試出web應用服務器系統的瓶頸值,因此在Nginx配置文件中upstream 模塊配置基礎負載IP 哈希均衡算法以及后端服務器數據接收轉發方式。

2.2.3 Tsung分布式配置

在實際應用中,為了避免多臺測試機器同時分布式運作,需要把主從機配置成免登陸方式,即Tsung分布式集群的機器之間實現無密碼的ssh登錄,將公鑰復制到從機/root/.ssh下,并改名為authorized_keys,如果需要本地允許無密碼登錄,可將自己生成的id_rsa.pub內容追加到authorized_keys下,即可完成免登陸配置。

2.2.4實驗結果

經過對上節的單點測試結果的分析,對系統參數進行優化配置、增加負載均衡、壓縮圖片、增加帶寬等處理后,重復上節進行單點測試計劃,逐步增加并發用戶數目以達到分布式負載測試。圖6為多臺同時并發1000用戶數下的結果圖。

圖6 Tsung每秒并發1000用戶結果圖

在分布式測試策略下發現,模擬用戶數每秒最大可突破1000個,系統處理請求的能力在負載均衡的調度下,處理能力比單機模式有顯著提高,瞬間處理每秒5000 個請求,產生的最大用戶數最高為25000個每秒,頁面響應尚可。因此在實際應用生產過程中結合Nignx 負載均衡的算法性能,采用least_conn結合的自適應負載算法模式,該模式滿足網絡服務高可用、高性能要求,通過實驗測試web應用服務器、CPU 平穩運行。

3 總結

本文基于農村電影數字節目交易平臺,利用壓力測試軟件對平臺的負載性能進行測試。通過比較Tsung、Jmeter、Load Runner三種不同壓力測試軟件的優缺點,最終選擇適合本平臺的Tsung開源測試軟件,并利用Tsung軟件對平臺的web應用服務器進行負載性能測試。本次應用先后采用單點負載測試和分布式集群負載相結合方式進行壓力測試,并給出性能測試結果。該應用的實現為平臺有針對性的從機器參數、軟硬均衡等方面進行全面優化和升級提供主要參考依據。經過實驗證明,經過優化升級的平臺在原有平臺的基礎上提升了容載及處理能力,有效保證了高訪問量壓力,保證了用戶體驗的滿意度。?