基于容器技术的性能测试服务资源管理

王晓冉　王　伟　陈铁南　袁鑫晨　支孟轩

1(中国科学院软件研究所软件工程技术研究开发中心　北京 100190)2(中国科学院大学　北京 100049)



基于容器技术的性能测试服务资源管理

王晓冉1,2王伟1陈铁南1,2袁鑫晨1,2支孟轩1

1(中国科学院软件研究所软件工程技术研究开发中心北京 100190)2(中国科学院大学北京 100049)

摘要软件性能测试通过模拟正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，是典型的资源密集型工作。云计算为软件性能测试提供了新的应用模式，测试用户(租户)不必部署和管理数量庞大的负载生成服务器或价格昂贵的测试软件，而是通过浏览器使用性能测试服务，依据测试资源的使用时间、使用量进行付费。基于云计算的性能测试可以屏蔽软硬件测试资源的管理复杂性，但测试资源的弹性供给和多租户共享仍面临技术挑战。分析性能测试的资源需求与测试脚本、负载量之间的关系，提出基于轻量化容器技术的测试资源弹性管理机制，并基于开源性能测试工具Bench4Q进行系统实现和实验分析。结果表明，所提出的方法能够准确估算租户所需的测试资源，并实现资源弹性分配，提高了资源利用率。

关键词性能测试资源评估容器弹性资源分配

0引言

软件性能测试通过自动化的测试工具模拟正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能测试工具根据测试需求模拟不同规模的负载强度,需要大量的软硬件投入,是典型的资源密集型系统。云计算技术的资源弹性供给、多租户共享等特征，改变了性能测试的使用模式[1]，出现了LoadImpact、JMeter Load Testing Cloud、Loader.io、LoadStorm等基于云计算环境的性能测试服务。使用性能测试服务，测试用户无需购置软硬件就可以按需使用测试资源、生成测试负载，节约了测试成本。

基于云计算的性能测试可以屏蔽软硬件测试资源的管理复杂性，但测试资源的弹性供给和多租户共享仍面临技术挑战。首先，测试资源需求与租户提交的测试任务相关，即使是同一测试任务，其负载行为也可能具有时变性，比如负载量的变化。因此，为了实现测试资源的弹性供给、提高资源利用率，需要动态评估测试资源需求。其次，在测试资源共享环境下，在满足租户测试任务的资源需求的同时，需要避免租户资源竞争，保障租户性能隔离。由于在线的性能测试服务存在大量的“小、微”规模负载测试需求的“长尾”租户，而传统基于虚拟机的租户隔离技术存在系统开销大的问题[2-5]，因此需要实现轻量化的多租户测试资源管理。

针对上述问题，本文提出基于容器技术的测试资源管理机制。首先，根据测试任务运行时的资源需求与测试脚本、负载量之间的关系，针对不同的测试任务建立相应的评估模型，估算租户资源需求。其次，使用轻量化容器替代虚拟机，根据租户的测试资源需求，在操作系统层动态创建容器，并根据资源需求变化，为测试任务弹性分配资源。实验结果表明，该方法能够准确估算租户所需的测试资源，并实现资源弹性分配，提高了资源利用率。

1相关工作

1.1容器技术

容器是操作系统级的虚拟化技术，系统内核通过为容器创建独立的命名空间和限制容器使用系统资源上限来实现容器间的隔离。容器直接调度系统内核执行命令，无需任何翻译机制，因此比虚拟机的资源开销更小、启动速度更快、更加轻量化[2]。容器技术的典型代表包括LXC、Linux-Vserver和OpendVZ，其中LXC已被集成到Linux操作系统内核中[5]。LXC容器有自己独立的进程、网络、文件系统、IPC等命名空间，通过Cgroup限制容器的系统资源[2]。

文献[5]提出了基于容器技术的任务管理模块。该模块负责执行任务、监测资源、保证任务间性能隔离。该模块为新的测试任务创建容器、配置容器资源，在容器内执行任务，并向任务执行引擎返回执行任务的ID。每个任务执行都占用一个单独的容器，不同任务间实现相互隔离。文中通过实验验证了使用容器技术既保证了任务的性能隔离，又提高了资源利用率。

1.2性能测试服务的资源管理

文献[14] 提出了性能测试服务的架构。该架构中使用IaaS,例如AWS，提供的服务器节点作为测试资源，每个服务器节点上部署多个虚拟机作为测试机。该架构中测试资源的管理主要由三个模块组成：资源池管理模块、资源监测模块、虚拟机迁移模块。系统根据用户输入的测试资源需求为一次性能测试分配测试机。在测试运行过程中，若监测到测试机出现资源瓶颈，则通过虚拟机迁移来保证性能测试的服务质量。测试资源的使用由测试软件的负载生成器产生，不同的负载生成器、负载生成器的升级、待测系统的升级等因素都会导致测试资源需求的变化。因此文中提出的依靠用户指定测试资源，经常会出现测试资源瓶颈或测试资源利用率低的情况。虽然提出通过虚拟机的迁移来解决资源瓶颈问题，但系统消耗大且不灵活。

文献[15]提出了通过估算单位负载量所需测试资源。计算每台虚拟机可以运行的最大负载量，进而计算每个性能测试任务所需的测试机的数量，资源需求无需用户配置。但是文中只介绍了两种估算服务资源需求的方法，且这两种方法都存在不足：(1)直接度量方法。需要向性能测试系统和操作系统注入代码，度量负载生成器实际资源消耗，实现过于复杂。(2)统计推断方法。针对每个待测系统的每个行为，统计负载生成器模拟该行为时的资源消耗。待测系统更新后，需要重新统计。当待测系统比较庞大或者不断更新时，该方法不可行。

2评估测试资源

2.1测试任务模型

测试任务由测试脚本和测试场景组成。测试脚本描述一组针对待测系统的负载行为，测试场景可以定义为负载量随时间变化的分段函数：l为测试负载量，t为测试时间。例如图1所示，测试场景A的分段函数：

其中，t的单位是分钟，单位负载表示待测系统的一个虚拟用户。假设虚拟用户之间相互独立，则可以对测试场景进行纵向分解，即一个测试场景可以按照测试负载量划分为多个测试场景，由多个负载生成器共同完成测试任务，如图1所示。例如，测试场景A在测试负载量是600处分解为测试场景B和测试场景C，分别用分段函数l1和l2表示：

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

图1　测试场景示例

2.2测试资源评估函数

本节通过研究测试资源需求与测试脚本、负载量的关系，针对每个测试脚本建立测试资源评估函数。测试资源包括CPU、网络I/O。内存资源由于受程序语言的垃圾回收机制影响，不在本文讨论范围内。

2.2.1测试资源需求与测试脚本、负载量的关系

在执行测试任务时，测试资源的使用主要由测试软件的负载生成器产生。负载生成器在执行不同测试任务的测试脚本时，由于脚本中描述的负载行为、待测系统不同，导致测试资源的需求也不同。图2显示了两个不同的测试脚本在相同测试场景下的网络I/O资源的使用情况对比图。执行脚本A时，资源使用随负载增长速率比执行脚本B时快。

图2　不同测试脚本的下行网络带宽对比

负载生成器在执行测试任务时，根据脚本中定义的负载行为，利用线程模拟虚拟用户向待测系统发送负载请求并接受响应，同时根据测试场景设定动态调整线程数量。当测试资源未出现瓶颈时，假设负载生成器每秒发送的请求数量与线程数量成正比，则由排队论可知[6]，测试资源占用率与负载生成器执行的负载量是线性关系，如下所示：

ρ=λS

(1)

其中，ρ表示测试资源利用率，λ表示请求发送率，S表示单位负载的测试资源占用时间。对于不同的测试任务，由于测试脚本S的不同，因此需要动态评估测试资源需求。

2.2.2建立评估函数

根据2.2.1节中描述的测试资源需求与测试脚本、负载量之间的关系，对于同一个测试脚本，r和l是线性关系。其中r表示单位时间内测试资源的使用量，l表示负载量。因此，可以根据样本数据集{(r1,l1),(r2,l2),…,(rn,ln)},使用线性回归的区间估计方法，建立评估函数，计算在指定负载量和设定的置信区间下测试资源的取值范围，取区间上限值作为评估资源。

(1) 获取样本数据

在测试任务启动后，增加测试资源评估阶段来获取样本数据。在评估阶段，测试资源需要根据经验进行初始化分配，并且，需要限定该阶段的最大测试负载量以避免测试资源和待测系统出现瓶颈而导致样本数据异常。基于上述考虑，给出评估阶段的测试场景函数l(t)：

(2)

其中，te表示评估阶段的执行时间，lmax表示评估阶段的最大测试负载量。

(2) 建立评估函数

基于线性回归区间估计，首先建立回归方程，如式(3)所示；其次根据设定的置信区间，建立计算置信区间的上限值方程，如式(4)所示，其中r0=a+bl0，α为置信区间，ur为抽样平均误差。式(3)和式(4)为测试资源评估函数：

r=a+bll>0

(3)

r=r0+tα/2url>0

(4)

根据样本数据，本文使用最小二乘法确定式(3)的参数，计算参数a和参数b的公式如下所示：

(5)

(6)

其中，n表示样品数量。

2.3测试资源评估算法

本节基于测试资源评估函数，给出测试资源评估算法，如算法1所示。本文中的资源评估方法，其前提条件如式(1)所示，需要设置负载生成器执行的最大负载量上限，避免线程过多导致系统调度占用资源，干扰资源评估的准确率。

算法1中涉及到的符号定义如下：

•S为测试场景。若使用P(t,l)表示测试场景中分段函数的终点，则S可以表示为P(t,l)集合，即S={P(0,0),P1,P2,…,Pn}，size(S)表示S中包含P(t,l)的个数，S[i]表示Pi。

•R为测试场景资源需求，可表示为r随t变化的分段函数。若使用P(t,r)表示测试场景中分段函数的终点，则R可表示为P(t,r)的集合，即R={P(0,0),P1,P2,…,Pn},R[i]表示Pi。

•estimate(l)表示由式(3)和式(4)建立的资源评估函数。

•max表示测试负载生成器执行的负载量上限。

算法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时，根据测试场景和资源评估函数评估资源需求。如算法1中的Resource-Estimation模块所示：遍历测试场景S中分段函数的每个终点S[i]，通过计算每个点的资源需求，构建资源需求场景。若S[i]的测试负载量是0，则测试资源需求为0；否则，根据资源评估函数计算测试资源需求。

当测试场景中的测试负载量大于max时，首先需要纵向分解为m个测试场景，如算法1中Scenario-Division模块所示：针对从测试场景1到测试场景m中每个测试场景,首先计算每个测试场景Si负载量范围(max*i-1,max*i)，再遍历测试场景S的所有分段函数。若分段函数负载量和测试场景Si的负载量范围有交集，则取交集部分的分段函数加入到测试场景中Si。分解后的测试场景最大负载量均小于等于max，可以使用Resource-Estimation 模块计算每个测试场景的资源需求。其中m可使用式(7)计算：

(7)

3基于容器技术的弹性资源分配

本节基于容器技术给出测试资源的弹性分配方法。该方法针对第2节中输出的测试场景资源需求集合{R1,R2,…,Rm}，根据Ri的资源使用量及使用周期，在测试过程中动态创建、删除容器Ci。具体过程如算法2所示。当Ri的起始时间R[1].t加上测试开始时间start_time等于当前系统时间时，根据Ri创建容器Ci，Ci的资源配置为Ri的峰值；当Ri的结束时间R[size(R)]加上测试开始时间等于当前系统时间，删除容器Ci。其中size(R)表示R中点的个数，current_time表示当前系统时间。与基于资源峰值需求的静态分配方法相比，本文方法动态适应测试资源需求变化，在测试资源有限的环境下可提高资源利用率。

算法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

在测试资源有限的环境下，由于多个测试任务同时执行，算法2在执行过程中存在测试资源申请冲突的问题，可能导致容器创建失败，测试任务无法完成。为避免这种情况，本文给出测试资源预订方法，如算法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实验环境

实验在开源性能测试软件Bench4Q[13]基础上实现本文提出的方法。其中，负载生成器使用的服务器硬件配置为8核CPU、 16 GB内存、上行网络带宽100 Mb/s、下行网络带宽100 Mb/s,操作系统为Ubuntu 14.04.1 LTS，容器采用Docker 1.3.1；每个负载生成器执行的最大负载量为600；测试资源评估阶段的容器资源配置为2个CPU、1 GB内存、下行网络带宽10 Mb/s、上行网络带宽10 Mb/s，评估时间为3分钟。

4.2资源评估方法验证

本实验针对10个不同测试任务的下行网络带宽资源，对比执行测试任务的实际测试资源使用量和评估值之间的标准差。图3显示其中两个测试任务的实际测试资源使用量和评估值对比情况，资源评估值比实际资源消耗值略大，但是相差很小。表1显示了所有测试任务的评估值标准差。可以看到，标准差是测试资源实际使用量的10%左右，相差较小。图3和表1的实验结果说明了本文提出的资源评估方法准确率较高。

图3　测试资源评估值与实际使用值对比

脚本带宽标准差(kB/s)实际带宽使用平均值(kB/s)1193122795203126742417610265120109462521365712415568206179891992024102132171

4.3弹性分配资源方法验证

本实验通过一个具体应用实例，对比弹性资源分配方法和基于资源峰值需求的静态分配方法的资源使用情况。实验使用的测试场景如图4所示，最大测试负载量是2500，测试时间是180分钟。经过评估获得四个测试场景的下行网络带宽资源需求，如图5所示：四个测试场景的资源需求峰值都是768 kB/s,测试场景1资源占用时间范围是0～180分钟，测试场景2资源占用时间范围是15～165分钟，测试场景3资源占用时间范围是30～150分钟，测试场景4资源占用时间范围是45～135分钟。

图4　实验使用的测试场景

图5　四个测试场景资源评估值

图6　两种资源分配方法资源使用对比

图6中对比了使用弹性资源分配方法和基于资源峰值需求的静态分配方法的下行网络带宽资源使用情况。弹性资源分配方法根据图5中分解后的四个测试场景资源需求，在测试过程中，为四个测试场景动态创建容器。为测试场景1创建的容器生命周期是0～180分钟;为测试场景2创建的容器生命周期是15～165分钟；为测试场景3创建的容器生命周期是30～150分钟；为测试场景4创建的容器生命周期是45～135分钟。每个容器的下行网络带宽配置是768 kB/s。由图6可以看出，针对本次测试任务，使用弹性资源分配方法分配测试资源，网络带宽资源节约了27%，证明了该方法提高了测试资源的利用率。

5结语

本文首先针对性能测试任务，提出了资源评估方法，可以较准确地评估测试任务的资源需求。其次，使用基于轻量化容器技术隔离多租户性能，通过动态创建容器实现弹性分配测试资源，在满足测试资源需求的前提下，提高测试资源利用率。

参考文献

[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