王曉冉　王　偉　陳鐵南　袁鑫晨　支孟軒

1(中國科學院軟件研究所軟件工程技術研究開發(fā)中心　北京 100190)2(中國科學院大學　北京 100049)

?

基于容器技術的性能測試服務資源管理

王曉冉1,2王偉1陳鐵南1,2袁鑫晨1,2支孟軒1

1(中國科學院軟件研究所軟件工程技術研究開發(fā)中心北京 100190)2(中國科學院大學北京 100049)

摘要軟件性能測試通過模擬正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試，是典型的資源密集型工作。云計算為軟件性能測試提供了新的應用模式，測試用戶(租戶)不必部署和管理數(shù)量龐大的負載生成服務器或價格昂貴的測試軟件，而是通過瀏覽器使用性能測試服務，依據(jù)測試資源的使用時間、使用量進行付費。基于云計算的性能測試可以屏蔽軟硬件測試資源的管理復雜性，但測試資源的彈性供給和多租戶共享仍面臨技術挑戰(zhàn)。分析性能測試的資源需求與測試腳本、負載量之間的關系，提出基于輕量化容器技術的測試資源彈性管理機制，并基于開源性能測試工具Bench4Q進行系統(tǒng)實現(xiàn)和實驗分析。結果表明，所提出的方法能夠準確估算租戶所需的測試資源，并實現(xiàn)資源彈性分配，提高了資源利用率。

關鍵詞性能測試資源評估容器彈性資源分配

0引言

軟件性能測試通過自動化的測試工具模擬正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。性能測試工具根據(jù)測試需求模擬不同規(guī)模的負載強度,需要大量的軟硬件投入,是典型的資源密集型系統(tǒng)。云計算技術的資源彈性供給、多租戶共享等特征，改變了性能測試的使用模式[1]，出現(xiàn)了LoadImpact、JMeter Load Testing Cloud、Loader.io、LoadStorm等基于云計算環(huán)境的性能測試服務。使用性能測試服務，測試用戶無需購置軟硬件就可以按需使用測試資源、生成測試負載，節(jié)約了測試成本。

基于云計算的性能測試可以屏蔽軟硬件測試資源的管理復雜性，但測試資源的彈性供給和多租戶共享仍面臨技術挑戰(zhàn)。首先，測試資源需求與租戶提交的測試任務相關，即使是同一測試任務，其負載行為也可能具有時變性，比如負載量的變化。因此，為了實現(xiàn)測試資源的彈性供給、提高資源利用率，需要動態(tài)評估測試資源需求。其次，在測試資源共享環(huán)境下，在滿足租戶測試任務的資源需求的同時，需要避免租戶資源競爭，保障租戶性能隔離。由于在線的性能測試服務存在大量的“小、微”規(guī)模負載測試需求的“長尾”租戶，而傳統(tǒng)基于虛擬機的租戶隔離技術存在系統(tǒng)開銷大的問題[2-5]，因此需要實現(xiàn)輕量化的多租戶測試資源管理。

針對上述問題，本文提出基于容器技術的測試資源管理機制。首先，根據(jù)測試任務運行時的資源需求與測試腳本、負載量之間的關系，針對不同的測試任務建立相應的評估模型，估算租戶資源需求。其次，使用輕量化容器替代虛擬機，根據(jù)租戶的測試資源需求，在操作系統(tǒng)層動態(tài)創(chuàng)建容器，并根據(jù)資源需求變化，為測試任務彈性分配資源。實驗結果表明，該方法能夠準確估算租戶所需的測試資源，并實現(xiàn)資源彈性分配，提高了資源利用率。

1相關工作

1.1容器技術

容器是操作系統(tǒng)級的虛擬化技術，系統(tǒng)內核通過為容器創(chuàng)建獨立的命名空間和限制容器使用系統(tǒng)資源上限來實現(xiàn)容器間的隔離。容器直接調度系統(tǒng)內核執(zhí)行命令，無需任何翻譯機制，因此比虛擬機的資源開銷更小、啟動速度更快、更加輕量化[2]。容器技術的典型代表包括LXC、Linux-Vserver和OpendVZ，其中LXC已被集成到Linux操作系統(tǒng)內核中[5]。LXC容器有自己獨立的進程、網絡、文件系統(tǒng)、IPC等命名空間，通過Cgroup限制容器的系統(tǒng)資源[2]。

文獻[5]提出了基于容器技術的任務管理模塊。該模塊負責執(zhí)行任務、監(jiān)測資源、保證任務間性能隔離。該模塊為新的測試任務創(chuàng)建容器、配置容器資源，在容器內執(zhí)行任務，并向任務執(zhí)行引擎返回執(zhí)行任務的ID。每個任務執(zhí)行都占用一個單獨的容器，不同任務間實現(xiàn)相互隔離。文中通過實驗驗證了使用容器技術既保證了任務的性能隔離，又提高了資源利用率。

1.2性能測試服務的資源管理

文獻[14] 提出了性能測試服務的架構。該架構中使用IaaS,例如AWS，提供的服務器節(jié)點作為測試資源，每個服務器節(jié)點上部署多個虛擬機作為測試機。該架構中測試資源的管理主要由三個模塊組成：資源池管理模塊、資源監(jiān)測模塊、虛擬機遷移模塊。系統(tǒng)根據(jù)用戶輸入的測試資源需求為一次性能測試分配測試機。在測試運行過程中，若監(jiān)測到測試機出現(xiàn)資源瓶頸，則通過虛擬機遷移來保證性能測試的服務質量。測試資源的使用由測試軟件的負載生成器產生，不同的負載生成器、負載生成器的升級、待測系統(tǒng)的升級等因素都會導致測試資源需求的變化。因此文中提出的依靠用戶指定測試資源，經常會出現(xiàn)測試資源瓶頸或測試資源利用率低的情況。雖然提出通過虛擬機的遷移來解決資源瓶頸問題，但系統(tǒng)消耗大且不靈活。

文獻[15]提出了通過估算單位負載量所需測試資源。計算每臺虛擬機可以運行的最大負載量，進而計算每個性能測試任務所需的測試機的數(shù)量，資源需求無需用戶配置。但是文中只介紹了兩種估算服務資源需求的方法，且這兩種方法都存在不足：(1)直接度量方法。需要向性能測試系統(tǒng)和操作系統(tǒng)注入代碼，度量負載生成器實際資源消耗，實現(xiàn)過于復雜。(2)統(tǒng)計推斷方法。針對每個待測系統(tǒng)的每個行為，統(tǒng)計負載生成器模擬該行為時的資源消耗。待測系統(tǒng)更新后，需要重新統(tǒng)計。當待測系統(tǒng)比較龐大或者不斷更新時，該方法不可行。

2評估測試資源

2.1測試任務模型

測試任務由測試腳本和測試場景組成。測試腳本描述一組針對待測系統(tǒng)的負載行為，測試場景可以定義為負載量隨時間變化的分段函數(shù)：l為測試負載量，t為測試時間。例如圖1所示，測試場景A的分段函數(shù)：

其中，t的單位是分鐘，單位負載表示待測系統(tǒng)的一個虛擬用戶。假設虛擬用戶之間相互獨立，則可以對測試場景進行縱向分解，即一個測試場景可以按照測試負載量劃分為多個測試場景，由多個負載生成器共同完成測試任務，如圖1所示。例如，測試場景A在測試負載量是600處分解為測試場景B和測試場景C，分別用分段函數(shù)l1和l2表示：

l0(t)=l1(t)+l2(t)(0≤t≤120)

圖1　測試場景示例

2.2測試資源評估函數(shù)

本節(jié)通過研究測試資源需求與測試腳本、負載量的關系，針對每個測試腳本建立測試資源評估函數(shù)。測試資源包括CPU、網絡I/O。內存資源由于受程序語言的垃圾回收機制影響，不在本文討論范圍內。

2.2.1測試資源需求與測試腳本、負載量的關系

在執(zhí)行測試任務時，測試資源的使用主要由測試軟件的負載生成器產生。負載生成器在執(zhí)行不同測試任務的測試腳本時，由于腳本中描述的負載行為、待測系統(tǒng)不同，導致測試資源的需求也不同。圖2顯示了兩個不同的測試腳本在相同測試場景下的網絡I/O資源的使用情況對比圖。執(zhí)行腳本A時，資源使用隨負載增長速率比執(zhí)行腳本B時快。

圖2　不同測試腳本的下行網絡帶寬對比

負載生成器在執(zhí)行測試任務時，根據(jù)腳本中定義的負載行為，利用線程模擬虛擬用戶向待測系統(tǒng)發(fā)送負載請求并接受響應，同時根據(jù)測試場景設定動態(tài)調整線程數(shù)量。當測試資源未出現(xiàn)瓶頸時，假設負載生成器每秒發(fā)送的請求數(shù)量與線程數(shù)量成正比，則由排隊論可知[6]，測試資源占用率與負載生成器執(zhí)行的負載量是線性關系，如下所示：

ρ=λS

(1)

其中，ρ表示測試資源利用率，λ表示請求發(fā)送率，S表示單位負載的測試資源占用時間。對于不同的測試任務，由于測試腳本S的不同，因此需要動態(tài)評估測試資源需求。

2.2.2建立評估函數(shù)

根據(jù)2.2.1節(jié)中描述的測試資源需求與測試腳本、負載量之間的關系，對于同一個測試腳本，r和l是線性關系。其中r表示單位時間內測試資源的使用量，l表示負載量。因此，可以根據(jù)樣本數(shù)據(jù)集{(r1,l1),(r2,l2),…,(rn,ln)},使用線性回歸的區(qū)間估計方法，建立評估函數(shù)，計算在指定負載量和設定的置信區(qū)間下測試資源的取值范圍，取區(qū)間上限值作為評估資源。

(1) 獲取樣本數(shù)據(jù)

在測試任務啟動后，增加測試資源評估階段來獲取樣本數(shù)據(jù)。在評估階段，測試資源需要根據(jù)經驗進行初始化分配，并且，需要限定該階段的最大測試負載量以避免測試資源和待測系統(tǒng)出現(xiàn)瓶頸而導致樣本數(shù)據(jù)異常?；谏鲜隹紤]，給出評估階段的測試場景函數(shù)l(t)：

(2)

其中，te表示評估階段的執(zhí)行時間，lmax表示評估階段的最大測試負載量。

(2) 建立評估函數(shù)

基于線性回歸區(qū)間估計，首先建立回歸方程，如式(3)所示；其次根據(jù)設定的置信區(qū)間，建立計算置信區(qū)間的上限值方程，如式(4)所示，其中r0=a+bl0，α為置信區(qū)間，ur為抽樣平均誤差。式(3)和式(4)為測試資源評估函數(shù)：

r=a+bll>0

(3)

r=r0+tα/2url>0

(4)

根據(jù)樣本數(shù)據(jù)，本文使用最小二乘法確定式(3)的參數(shù)，計算參數(shù)a和參數(shù)b的公式如下所示：

(5)

(6)

其中，n表示樣品數(shù)量。

2.3測試資源評估算法

本節(jié)基于測試資源評估函數(shù)，給出測試資源評估算法，如算法1所示。本文中的資源評估方法，其前提條件如式(1)所示，需要設置負載生成器執(zhí)行的最大負載量上限，避免線程過多導致系統(tǒng)調度占用資源，干擾資源評估的準確率。

算法1中涉及到的符號定義如下：

?S為測試場景。若使用P(t,l)表示測試場景中分段函數(shù)的終點，則S可以表示為P(t,l)集合，即S={P(0,0),P1,P2,…,Pn}，size(S)表示S中包含P(t,l)的個數(shù)，S[i]表示Pi。

?R為測試場景資源需求，可表示為r隨t變化的分段函數(shù)。若使用P(t,r)表示測試場景中分段函數(shù)的終點，則R可表示為P(t,r)的集合，即R={P(0,0),P1,P2,…,Pn},R[i]表示Pi。

?estimate(l)表示由式(3)和式(4)建立的資源評估函數(shù)。

?max表示測試負載生成器執(zhí)行的負載量上限。

算法1評估測試資源算法

Module Resource-Estimation

Input:S,estimate(l)

Output:R

for i from 1 to size(S)

if S[i].l=0 then

R[i].r←0;

else

R[i].r←estimate(S[i].l);

end if

R[i].t←S[i].t;

add R[i] to R;

end for

Module Scenario-Division

Input:S,max

Output:{S1,S2,…,Sm}

add S[1] to S1

for i from 1 to m

for j from 2 to size(S)

if S [j].l between (max*i-1,max*i)then

add S [J] to Si;

end if

if S[j-1].lmax*ithen

find SP between S[j] and S [j-1];

//SP.l=max*i;

add SP to Si;

end if

if S[j-1].l>max*i && S[j].l

find SP between S[j] and S[j-1];

//SP.l=max*i;

add SP to Si;

end if

end for

end for

當測試場景中的負載量小于等于max時，根據(jù)測試場景和資源評估函數(shù)評估資源需求。如算法1中的Resource-Estimation模塊所示：遍歷測試場景S中分段函數(shù)的每個終點S[i]，通過計算每個點的資源需求，構建資源需求場景。若S[i]的測試負載量是0，則測試資源需求為0；否則，根據(jù)資源評估函數(shù)計算測試資源需求。

當測試場景中的測試負載量大于max時，首先需要縱向分解為m個測試場景，如算法1中Scenario-Division模塊所示：針對從測試場景1到測試場景m中每個測試場景,首先計算每個測試場景Si負載量范圍(max*i-1,max*i)，再遍歷測試場景S的所有分段函數(shù)。若分段函數(shù)負載量和測試場景Si的負載量范圍有交集，則取交集部分的分段函數(shù)加入到測試場景中Si。分解后的測試場景最大負載量均小于等于max，可以使用Resource-Estimation 模塊計算每個測試場景的資源需求。其中m可使用式(7)計算：

(7)

3基于容器技術的彈性資源分配

本節(jié)基于容器技術給出測試資源的彈性分配方法。該方法針對第2節(jié)中輸出的測試場景資源需求集合{R1,R2,…,Rm}，根據(jù)Ri的資源使用量及使用周期，在測試過程中動態(tài)創(chuàng)建、刪除容器Ci。具體過程如算法2所示。當Ri的起始時間R[1].t加上測試開始時間start_time等于當前系統(tǒng)時間時，根據(jù)Ri創(chuàng)建容器Ci，Ci的資源配置為Ri的峰值；當Ri的結束時間R[size(R)]加上測試開始時間等于當前系統(tǒng)時間，刪除容器Ci。其中size(R)表示R中點的個數(shù)，current_time表示當前系統(tǒng)時間。與基于資源峰值需求的靜態(tài)分配方法相比，本文方法動態(tài)適應測試資源需求變化，在測試資源有限的環(huán)境下可提高資源利用率。

算法2測試資源分配算法

AlgorithmLallocate testing resource

InputLRSet={R1,R2,…,Rm},start time(測試開始時間)

Output:NULL

while current_time

for each R in RSet

if R[1].t+start_time=current_time then

max_r←max(R.l);//資源峰值

end if

if R[size(R)].t+start_time=current_time then

delete container Ci;

end if

end for

sleep a while;

end while

在測試資源有限的環(huán)境下，由于多個測試任務同時執(zhí)行，算法2在執(zhí)行過程中存在測試資源申請沖突的問題，可能導致容器創(chuàng)建失敗，測試任務無法完成。為避免這種情況，本文給出測試資源預訂方法，如算法3所示。測試資源池Resource[r][t]包含資源和時間兩個維度，對于每個測試場景資源需求Ri，判斷在其資源使用時間，測試資源池中的可用資源是否能夠滿足資源需求的最大值。如果能夠滿足，則預訂該時間段的資源；否則回滾此次所有預訂資源的操作。

算法3預定測試資源算法

Algorithm:book testing resource

Input:RSet={R1,R2,…,Rm},start_time(測試開始時間),Resource[r][t](當前測試資源,r表示資源量，t表示時間)

Otuput:ture or false

for each R in RSet

for time between R [1].t to R [size(R)]t

if Resource[][time+start_time]>=max(R.r)then

book Resource[max(R.r)][time+start_time];

continue;

else

rollback all book artion;

return false;

end if

end for

return true;

4實驗

4.1實驗環(huán)境

實驗在開源性能測試軟件Bench4Q[13]基礎上實現(xiàn)本文提出的方法。其中，負載生成器使用的服務器硬件配置為8核CPU、 16 GB內存、上行網絡帶寬100 Mb/s、下行網絡帶寬100 Mb/s,操作系統(tǒng)為Ubuntu 14.04.1 LTS，容器采用Docker 1.3.1；每個負載生成器執(zhí)行的最大負載量為600；測試資源評估階段的容器資源配置為2個CPU、1 GB內存、下行網絡帶寬10 Mb/s、上行網絡帶寬10 Mb/s，評估時間為3分鐘。

4.2資源評估方法驗證

本實驗針對10個不同測試任務的下行網絡帶寬資源，對比執(zhí)行測試任務的實際測試資源使用量和評估值之間的標準差。圖3顯示其中兩個測試任務的實際測試資源使用量和評估值對比情況，資源評估值比實際資源消耗值略大，但是相差很小。表1顯示了所有測試任務的評估值標準差。可以看到，標準差是測試資源實際使用量的10%左右，相差較小。圖3和表1的實驗結果說明了本文提出的資源評估方法準確率較高。

圖3　測試資源評估值與實際使用值對比

腳本帶寬標準差(kB/s)實際帶寬使用平均值(kB/s)1193122795203126742417610265120109462521365712415568206179891992024102132171

4.3彈性分配資源方法驗證

本實驗通過一個具體應用實例，對比彈性資源分配方法和基于資源峰值需求的靜態(tài)分配方法的資源使用情況。實驗使用的測試場景如圖4所示，最大測試負載量是2500，測試時間是180分鐘。經過評估獲得四個測試場景的下行網絡帶寬資源需求，如圖5所示：四個測試場景的資源需求峰值都是768 kB/s,測試場景1資源占用時間范圍是0～180分鐘，測試場景2資源占用時間范圍是15～165分鐘，測試場景3資源占用時間范圍是30～150分鐘，測試場景4資源占用時間范圍是45～135分鐘。

圖4　實驗使用的測試場景

圖5　四個測試場景資源評估值

圖6　兩種資源分配方法資源使用對比

圖6中對比了使用彈性資源分配方法和基于資源峰值需求的靜態(tài)分配方法的下行網絡帶寬資源使用情況。彈性資源分配方法根據(jù)圖5中分解后的四個測試場景資源需求，在測試過程中，為四個測試場景動態(tài)創(chuàng)建容器。為測試場景1創(chuàng)建的容器生命周期是0～180分鐘;為測試場景2創(chuàng)建的容器生命周期是15～165分鐘；為測試場景3創(chuàng)建的容器生命周期是30～150分鐘；為測試場景4創(chuàng)建的容器生命周期是45～135分鐘。每個容器的下行網絡帶寬配置是768 kB/s。由圖6可以看出，針對本次測試任務，使用彈性資源分配方法分配測試資源，網絡帶寬資源節(jié)約了27%，證明了該方法提高了測試資源的利用率。

5結語

本文首先針對性能測試任務，提出了資源評估方法，可以較準確地評估測試任務的資源需求。其次，使用基于輕量化容器技術隔離多租戶性能，通過動態(tài)創(chuàng)建容器實現(xiàn)彈性分配測試資源，在滿足測試資源需求的前提下，提高測試資源利用率。

參考文獻

[1] Murphy T E,Wilson N.Magic Quadrant for Integrated Software Quality Suites[J].Gartner Research,2013.

[2] Dua R,Raja A R,Kakadia D.Virtualization vs Containerization to Support PaaS[C]//Cloud Engineering (IC2E),2014 IEEE International Conference on.IEEE,2014:610-614.

[3] Xavier M G,Neves M V,Rossi F D,et al.Performance evaluation of container-based virtualization for high performance computing environments[C]//Parallel,Distributed and Network-Based Processing (PDP),2013 21st Euromicro International Conference on.IEEE,2013:233-240.

[4] Xavier M G,Neves M V,Rose C A F D.A Performance Comparison of Container-based Virtualization Systems for MapReduce Clusters[C]//Parallel,Distributed and Network-Based Processing (PDP),2014 22nd Euromicro International Conference on.IEEE,2014:299-306.

[5] Hong J,Balaji P,Wen G,et al.Container-Based Job Management for Fair Resource Sharing[C]//Supercomputing.Springer Berlin Heidelberg,2013:290-301.

[6] Gunther N J.Analyzing Computer System Performance with Perl:PDQ[M].Springer,2011.

[7] Dhingra M,Lakshmi J,Nandy S K,et al.Elastic Resources Framework in IaaS,preserving performance SLAs[C]//Cloud Computing (CLOUD),2013 IEEE Sixth International Conference on.IEEE,2013:430-437.

[8] Wei H,Zhou S,Yang T,et al.Elastic resource management for heterogeneous applications on PaaS[C]//Proceedings of the 5th Asia-Pacific Symposium on Internetware.ACM,2013:7.

[9] Shen Z,Subbiah S,Gu X,et al.Cloudscale:elastic resource scaling for multi-tenant cloud systems[C]//Proceedings of the 2nd ACM Symposium on Cloud Computing.ACM,2011:5.

[10] RedLine13[EB/OL].[2015].http://www.redline13.com.

[11] LoadImpact[EB/OL].[2015].http://loadimpact.com.

[12] LoadStrom[EB/OL].[2015].http://loadstorm.com/load-test-tool.

[13] Bench4Q[EB/OL].[2015].http://forge.ow2.org/projects/jaspte.

[14] Zhou J,Li S,Zhang Z,et al.Position paper:cloud-based performance testing:issues and challenges[C]//Proceedings of the 2013 international workshop on Hot topics in cloud services.ACM,2013:55-62.

[15] Zhang L,Chen Y,Tang F,et al.Design and implementation of cloud-based performance testing system for web services[C]//Communications and Networking in China (CHINACOM),2011 6th International ICST Conference on.IEEE,2011:875-880.

收稿日期：2015-02-08。國家自然科學基金項目(61402450)；科技支撐項目(2012BAH14B02)。王曉冉，碩士，主研領域：計算機軟件與理論。王偉，副研究員。陳鐵南，碩士。袁鑫晨，碩士。支孟軒，碩士。

中圖分類號TP3

文獻標識碼A

DOI:10.3969/j.issn.1000-386x.2016.07.002

CONTAINER-BASED SERVICES RESOURCE MANAGEMENT FOR PERFORMANCE TESTING

Wang Xiaoran1,2Wang Wei1Chen Tienan1,2Yuan Xinchen1,2Zhi Mengxuan1

1(TechnologyCenterofSoftwareEngineering,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190,China)2(UniversityofChineseAcademyofSciences,Beijing100049,China)

AbstractSoftware performance testing is implemented by simulating normal,peak and abnormal load conditions to test various performances of the system,it is a typical resource intensive operation.Cloud computing provides a new application model for software performance testing,the testing users (tenants) don’t have to deploy and manage a huge number of load generation servers or expensive test software,but use performance testing service via browser and pay according to the time and the amount of test resources.Performance testing based on cloud computing can shield the management complexity of software and hardware test resources,but elastic supply and multi-tenant sharing of test resources still face technical challenges.This paper analyses the relationship between resource requirement of performance testing and test scripts and loads,and proposes the lightweight container technology-based elastic management mechanism for testing resource,and implements it in Bench4Q,which is an open source performance testing tool,as well as conducts experimental analysis.Results show that the proposed method can estimate accurately the test resource the tenants needed,and achieves the elastic resource allocation,raises the resource utilisation rate.

KeywordsPerformance testingResource estimationContainerElastic resource allocation