基于容器技術(shù)的性能測(cè)試服務(wù)資源管理

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

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

?

基于容器技術(shù)的性能測(cè)試服務(wù)資源管理

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

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

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

關(guān)鍵詞性能測(cè)試資源評(píng)估容器彈性資源分配

0引言

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

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

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

1相關(guān)工作

1.1容器技術(shù)

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

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

1.2性能測(cè)試服務(wù)的資源管理

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

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

2評(píng)估測(cè)試資源

2.1測(cè)試任務(wù)模型

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

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

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

圖1　測(cè)試場(chǎng)景示例

2.2測(cè)試資源評(píng)估函數(shù)

本節(jié)通過(guò)研究測(cè)試資源需求與測(cè)試腳本、負(fù)載量的關(guān)系，針對(duì)每個(gè)測(cè)試腳本建立測(cè)試資源評(píng)估函數(shù)。測(cè)試資源包括CPU、網(wǎng)絡(luò)I/O。內(nèi)存資源由于受程序語(yǔ)言的垃圾回收機(jī)制影響，不在本文討論范圍內(nèi)。

2.2.1測(cè)試資源需求與測(cè)試腳本、負(fù)載量的關(guān)系

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

圖2　不同測(cè)試腳本的下行網(wǎng)絡(luò)帶寬對(duì)比

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

ρ=λS

(1)

其中，ρ表示測(cè)試資源利用率，λ表示請(qǐng)求發(fā)送率，S表示單位負(fù)載的測(cè)試資源占用時(shí)間。對(duì)于不同的測(cè)試任務(wù)，由于測(cè)試腳本S的不同，因此需要?jiǎng)討B(tài)評(píng)估測(cè)試資源需求。

2.2.2建立評(píng)估函數(shù)

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

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

在測(cè)試任務(wù)啟動(dòng)后，增加測(cè)試資源評(píng)估階段來(lái)獲取樣本數(shù)據(jù)。在評(píng)估階段，測(cè)試資源需要根據(jù)經(jīng)驗(yàn)進(jìn)行初始化分配，并且，需要限定該階段的最大測(cè)試負(fù)載量以避免測(cè)試資源和待測(cè)系統(tǒng)出現(xiàn)瓶頸而導(dǎo)致樣本數(shù)據(jù)異常。基于上述考慮，給出評(píng)估階段的測(cè)試場(chǎng)景函數(shù)l(t)：

(2)

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

(2) 建立評(píng)估函數(shù)

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

r=a+bll>0

(3)

r=r0+tα/2url>0

(4)

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

(5)

(6)

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

2.3測(cè)試資源評(píng)估算法

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

算法1中涉及到的符號(hào)定義如下：

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

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

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

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

算法1評(píng)估測(cè)試資源算法

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

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

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

(7)

3基于容器技術(shù)的彈性資源分配

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

算法2測(cè)試資源分配算法

AlgorithmLallocate testing resource

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

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

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

算法3預(yù)定測(cè)試資源算法

Algorithm:book testing resource

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

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實(shí)驗(yàn)

4.1實(shí)驗(yàn)環(huán)境

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

4.2資源評(píng)估方法驗(yàn)證

本實(shí)驗(yàn)針對(duì)10個(gè)不同測(cè)試任務(wù)的下行網(wǎng)絡(luò)帶寬資源，對(duì)比執(zhí)行測(cè)試任務(wù)的實(shí)際測(cè)試資源使用量和評(píng)估值之間的標(biāo)準(zhǔn)差。圖3顯示其中兩個(gè)測(cè)試任務(wù)的實(shí)際測(cè)試資源使用量和評(píng)估值對(duì)比情況，資源評(píng)估值比實(shí)際資源消耗值略大，但是相差很小。表1顯示了所有測(cè)試任務(wù)的評(píng)估值標(biāo)準(zhǔn)差?？梢钥吹?，標(biāo)準(zhǔn)差是測(cè)試資源實(shí)際使用量的10%左右，相差較小。圖3和表1的實(shí)驗(yàn)結(jié)果說(shuō)明了本文提出的資源評(píng)估方法準(zhǔn)確率較高。

圖3　測(cè)試資源評(píng)估值與實(shí)際使用值對(duì)比

腳本帶寬標(biāo)準(zhǔn)差(kB/s)實(shí)際帶寬使用平均值(kB/s)1193122795203126742417610265120109462521365712415568206179891992024102132171

4.3彈性分配資源方法驗(yàn)證

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

圖4　實(shí)驗(yàn)使用的測(cè)試場(chǎng)景

圖5　四個(gè)測(cè)試場(chǎng)景資源評(píng)估值

圖6　兩種資源分配方法資源使用對(duì)比

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

5結(jié)語(yǔ)

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

參考文獻(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。國(guó)家自然科學(xué)基金項(xiàng)目(61402450)；科技支撐項(xiàng)目(2012BAH14B02)。王曉冉，碩士，主研領(lǐng)域：計(jì)算機(jī)軟件與理論。王偉，副研究員。陳鐵南，碩士。袁鑫晨，碩士。支孟軒，碩士。

中圖分類號(hào)TP3

文獻(xiàn)標(biāo)識(shí)碼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