执行ubuntu8.04

软件学报ISSN1000-9825,CODENRUXUEWE-mail:jos@iscas.
ac.
cnJournalofSoftware,2013,24(8):17131730[doi:10.
3724/SP.
J.
1001.
2013.
04344]http://www.
jos.
org.
cn中国科学院软件研究所版权所有.
Tel/Fax:+86-10-62562563一种支持Java应用中计算按需远程执行的方法张颖1,2,黄罡1,2,刘儇哲1,2,梅宏1,2,李影2,3,杨顺祥1,2,31(北京大学信息科学技术学院软件研究所,北京100871)2(高可信软件技术教育部重点实验室(北京大学),北京100871)3(IBM中国研究院,北京100193)通讯作者:黄罡,E-mail:hg@pku.
edu.
cn,http://www.
sei.
pku.
edu.
cn/~huanggang摘要:按需远程执行是软件应用实现对资源按需占有,从而保障性能并提高资源利用率的重要手段.
给出了一种通过自动程序转换来支持Java应用中计算按需远程执行的方法,其核心是支持计算按需远程执行的设计模式.
介绍了将Java应用转换成该模式所面临的技术挑战、处理机制以及DPartner转换系统.
与已有工作相比,DPartner有两大特色:一是程序转换自动执行;二是转换后应用可实现真正按需的远程执行,使性能和资源利用率得以提升.
此外,DPartner被设计为可对只有Java字节码的遗产应用进行转换,更具实用性.
关键词:按需占有资源;远程执行;程序转换;性能中图法分类号:TP311文献标识码:A中文引用格式:张颖,黄罡,刘儇哲,梅宏,李影,杨顺祥.
一种支持Java应用中计算按需远程执行的方法.
软件学报,2013,24(8):17131730.
http://www.
jos.
org.
cn/1000-9825/4344.
htm英文引用格式:ZhangY,HuangG,LiuXZ,MeiH,LiY,YangSX.
Approachtosupportingon-demandremoteexecutionofthecomputationsinaJavaapplication.
RuanJianXueBao/JournalofSoftware,2013,24(8):17131730(inChinese).
http://www.
jos.
org.
cn/1000-9825/4344.
htmApproachtoSupportingOn-DemandRemoteExecutionoftheComputationsinaJavaApplicationZHANGYing1,2,HUANGGang1,2,LIUXuan-Zhe1,2,MEIHong1,2,LIYing2,3,YANGShun-Xiang1,2,31(InstituteofSoftware,SchoolofElectronicsEngineeringandComputerScience,PekingUniversity,Beijing100871,China)2(KeyLaboratoryofHighConfidenceSoftwareTechnologiesofMinistryofEducation(PekingUniversity),Beijing100871,China)3(IBMChinaResearchLaboratory,Beijing100193,China)Correspondingauthor:HUANGGang,E-mail:hg@pku.
edu.
cn,http://www.
sei.
pku.
edu.
cn/~huanggangAbstract:On-Demandremoteexecutingisanimportantwaytoenableanapplicationoccupyresourceon-demandtoguaranteeperformanceaswellasimproveresourceutilization.
Thispaperproposesanautomaticprogramtransformationapproachfortheon-demandremoteexecutionofthecomputationsinaJavaapplication.
Thecoreoftheapproachisadesignpatternsupportingon-demandremoteexecutionofcomputations.
Theresearchpresentsthetechnicalchallengesofandsolutionsfortransformation,andgivesouttheDPartnertransformationsystem.
Comparingwithpreviouswork,DPartnerhastwomajorcharacteristics:first,transformationiscarriedoutautomatically;second,thetransformedapplicationisabletoexecuteremotelyon-demand,soitsperformancecanbeimprovedandtheresourceutilizationcanbeincreased.
Additionally,DPartnerisdesignedtobeapracticabletool,asitcantransformlegacyapplicationswithonlyJavabytecode.
Keywords:resourceon-demand;remoteexecution;programtransformation;performance基金项目:国家自然科学基金(61222203,60933003,61121063);国家重点基础研究发展计划(973)(2009CB320703);国家高技术研究发展计划(863)(2013AA01A208,2012AA010107);新世纪优秀人才支持计划(NCET-09-0178);中国博士后科学基金(2013M530011)收稿时间:2012-01-01;定稿时间:2012-10-101714JournalofSoftware软件学报Vol.
24,No.
8,August2013对计算资源(如CPU、内存等)实现按需使用,是软件应用增强性能并提高资源利用率的一种主要手段[1].
所谓按需(on-demand),是指当计算资源不足时,应用可以占有并使用额外的资源,从而保障其高效运行;当资源过剩时,又可以释放掉多余的资源,从而减少浪费[2].
按需使用计算资源必须同时具备两个条件[3]:一是有灵活可用的额外资源;二是应用可以真正使用到这些资源.
在Internet环境下,虽然网络单节点的计算资源仍然有限,然而互连起来的网络节点其整体所拥有的计算资源则极为丰富.
当应用需要额外资源时,可以通过网络获得其他节点所拥有的资源.
因而可以看到,实现资源按需使用的根本仍在于应用自身.
应用对计算资源的使用方式主要有两种[4]:复制式和分割式.
复制式的资源使用方式通过对应用进行复制,将副本运行在额外的节点上,并在原应用及其副本前端加上负载平衡器来将用户请求转发到这些应用实例组成的集群上[5].
这种方式可使应用有效应对由于用户请求激增而性能急剧下降的情况.
然而已有研究指出,这种复制整个应用的方式在较大程度上会造成资源浪费[6].
其原因在于,通常情况下,组成应用的模块不全都亟需资源.
那些不亟需资源但占有资源的模块会与那些真正亟需资源的模块相竞争,造成隐性浪费.
因此,分割式资源使用方式将组成应用的模块分别部署在不同的节点上,让那些真正亟需资源的模块充分占有资源,以此实现对应用整体性能的保障以及对资源的充分利用[7,8].
在此基础上,又可将两种方式相结合,在较细的粒度上实现复制式资源使用,以进一步高效地保障应用性能.
由此可见,应用对计算资源的按需使用要以应用模块的按需分布式部署执行为保障,也就是说,需要实现应用中计算的按需远程执行.
远程执行主要有两种实现方式:(1)编写分布式应用,将应用中对资源消耗较大的计算在设计和实现时就安排到拥有较多资源的网络节点上执行.
然而,由于分布式应用要求开发者处理远程方法调用、序列化、同步等与程序分布相关的问题,因而编写起来通常费时、费力.
此外,由于开发者很难在设计实现时就准确预料到应用对资源的使用,因而所开出的应用程序中的本地/远程调用方式通常固定不变,这就使得应用对资源难以实现真正的按需使用.
(2)通过程序转换器自动将给定应用中的程序代码转换后分为两部分:一部分继续留在原节点上运行,另一部分则被移动到其他网络节点上运行.
这两部分之间所需要的跨网络的互操作代码由该转换器以打补丁的方式自动加入到原始应用当中,从而保证了转换后应用的正确运行.
这种方式不要求开发者编写与程序分布相关的代码,极大地降低了应用开发难度,因而成为近年来极具潜力的一个研究方向[9].
然而现有工作中,转换后应用代码中的本地/远程调用方式仍然固定不变,导致当资源变化而需要调整计算的本地/远程调用关系时必须停机、重转换、重启,因而难以实现应用在运行时对资源的按需使用.
本文以Internet上广泛存在的Java应用为对象,研究如何基于自动程序转换来实现其计算的按需远程执行.
提出了一种支持计算按需远程执行的设计模式,并着重介绍了在将给定应用转换为符合该模式的应用过程中所面临的主要技术挑战,包括:(1)正确性:自动识别出哪些应用类中的计算能够被转移到远程网络节点,从而保证转移后应用执行的正确性;(2)有效性:决定哪些可转移的应用类中的计算需要被真正转移到远程网络节点上执行,从而降低网络通信的开销以保障远程执行后应用的整体性能并提高资源利用率.
本文实现了名为DPartner的自动程序转换系统,将给定的Java应用转换为其计算可以按需远程执行的应用.
DPartner在Java字节码层次上实现转换,这使得它不但可用于新开发的应用,而且可用于遗产应用.
DPartner的输入为一个给定Java应用的字节码以及相关的资源文件(如图像文件、XML配置文件等).
输出为两类制品:一类为转换后的Java应用,该应用包含转换后的全部应用类和资源文件,且留在原网络节点上运行;另一类制品包含了从原应用中抽取出来的那些适合在远程网络节点上执行的应用类以及所使用的资源文件.
这样,转换后应用中对这些类的调用可直接在本地执行,也可根据需要被转发到在远端的对应类上去执行.
本文以JEE应用RUBiS[10]为例对DPartner进行了实验,并证明了计算按需远程执行后应用性能的提升.
本文主要贡献在于:(1)给出了一种支持Java应用中计算按需远程执行的设计模式.
(2)实现了名为DPartner的自动程序转换系统,将给定的Java应用转换为计算可按需远程执行的应用.
解决了转换过程中所面临的正确性、有效性等技术挑战.
(3)通过实验验证了DPartner的有效性,证明了计算按需远程执行能够保障应用性能,并且能够提高资源利用率.
张颖等:一种支持Java应用中计算按需远程执行的方法1715本文第1节给出支持Java应用中计算按需远程执行的设计模式.
第2节给出一个对应的例子.
第3节介绍DPartner如何通过字节码级的自动程序转换而将给定的Java应用转换为符合该模式从而可以按需远程执行的应用.
第4节通过一组实验证明DPartner在实现计算按需远程执行以保障应用性能上的有效性.
第5节介绍相关工作.
第6节总结全文并展望未来的工作.
1支持Java应用中计算按需远程执行的方法概述1.
1一种支持Java应用中计算按需远程执行的设计模式本文所给出的程序转换遵循重构的原则[11],即对给定应用程序的内部结构进行修改而不改变其外部功能.
转换包含如下3个基本要素:(1)给定Java应用所具有的原始程序结构,称为源结构(sourcestructure);(2)转换后Java应用所具有的新程序结构,称为目标结构(targetstructure);(3)一系列将源结构变为目标结构的转换操作.
我们首先介绍源结构以及目标结构,并在下一节中给出转换操作的概述.
一个给定的Java应用中的程序代码无外乎具有两种结构:一种是直接内存调用结构或称本地调用结构(localinvocation),如图1(a)所示;另一种是远程调用结构(remoteinvocation),如图1(b)所示.
(c)按需远程调用结构(目标结构)Fig.
1SourcestructureofaJavaapplicationandthetargetstructureitheldaftertransformation图1Java应用中程序的源结构以及转换后的目标结构在图1(a)中,应用类X调用应用类N的过程首先是获得对N的内存引用,然后通过该引用去调用所需要的方法.
显然,这种直接内存调用结构并不允许N中的计算被按需转移到远程执行.
倘若N转移到远程网络节点后,X不能从它所在的地址空间获得对在远端的N的引用.
在给定的应用中,还可能存在如图1(b)所示的远程调用结构.
X通过RCS(remotecommunicationservice,远程通信服务)获得运行在远端的N的引用,然后使用该引用去远程调用N中的方法.
在该结构中,由RCS负责将N的引用与N相关联.
以JEE为例,JEE的InitialContext就相当于RCS的关键部分.
X通过InitialContext获得了N的stub(即对N的远程引用),然后用其调用N.
尽管该结构允许N远程执行,却不能支持N实现按需远程执行.
原因在于,当N和X在同一地址空间时,X对N的方法调RemotecommunicationserviceNProxyEndpoint远程调用本地调用NIntf按需远程调用XNXN本地调用RemotecommunicationserviceNIntf远程调用NX(a)本地调用(源结构)(b)远程调用(源结构)1716JournalofSoftware软件学报Vol.
24,No.
8,August2013用仍需要RCS发消息给网络栈才能传递到N,而网络栈中的消息传递相对于直接内存引用来说极为耗时且耗资源,从而导致应用性能下降.
这与通过计算按需转移来保障应用性能并提高资源利用率的初衷相违背.
此外,在该结构中,X与RCS相绑定,当RCS改变时(如从TCP变为HTTP),X也不得不改变,带来了额外负担.
为了实现计算的按需远程执行,转换后应用的目标结构必须允许X能够有效调用N中的方法而不管当前X与N运行在同一地址空间还是在不同的网络节点.
我们给出了一种支持Java应用中计算按需远程执行的目标程序结构.
它主要包含如下两个核心元素:proxy和endpoint.
如图1(c)所示,我们将X和N之间的直接内存调用以及通过RCS的远程调用都转换成了经由proxy和endpoint进行的间接调用.
NProxy的外部行为和N完全一致,只是它本身不执行任何实际的计算操作,只负责将方法调用转发到N执行.
如果N的位置改变,比如从X所在的地址空间转移到了远程网络节点,或是从某一远程网络节点转移到了另一节点,X并不会知道N位置的变化.
Endpoint负责识别N当前的位置并负责X和N之间的跨网络互操作.
倘若N运行在远程节点,则endpoint会利用给定的RCS获得对N的远程引用,并把该引用以NProxy的形式供X使用,使得X能够通过该引用而远程调用N.
当X和N都运行在同一地址空间时,endpoint会直接获得对N的内存引用,并同样以NProxy的形式供X所用,使得X调用N时不必经过耗时的网络栈.
endpoint带来了两个好处:首先,它帮助实现了N中计算的按需远程执行.
当本地资源不足并且网络条件较好时,X可以通过endpoint调用在远端的N.
从而通过N中计算的远程执行来实现对额外资源的占有以提高应用性能.
当整体资源过剩或是网络条件不佳时,X则可通过endpoint直接调用在同一地址空间中的N,以保障应用性能并节约资源;其次,通过endpoint,X与具体的RCS相解耦.
即便是RCS改变,X和NProxy都不需要做任何变化,提高了应用对环境变化的适应性.
1.
2程序转换步骤在确定了Java应用的源结构以及目标结构以后,我们逐步实施如图2所示的程序转换步骤来实现给定Java应用中计算的按需远程执行,并保障远程执行后应用整体性能的提升以及资源的节省.
Fig.
2Transformationstepsfortheon-demandremoteexecutionofaJavaapplication图2Java应用中实现计算按需远程执行的主要转换步骤(1)应用类分类.
对于一个给定的Java应用,DPartner自动将其应用类,即字节码文件,分成anchored和movable两类.
anchored类型的应用类必须留在原网络节点上执行.
原因在于,这些类使用到了一些只能在原节点才能获取的特殊资源(比如图形用户界面显示器或特殊的文件).
倘若这些类被转移到远端网络节点上执行,它们会因找不到所需要的资源而造成执行错误.
这些类之外的其他应用类都被自动归为movable类型的类.
例如,一个用于数学处理的Math类就通常是一个movable类型的类.
必要时,这些类可以远程执行,从而通过对远程计算资源的占有来提高整个应用的性能.
(2)应用类转换.
在这一步中,我们会将给定Java应用从源结构转换为目标结构,使其可按需远程执行.
当一个应用类放到远端执行时,与之交互的应用类都需要被转换成可按需远程调用的结构,即生成被调用者的代理类proxy,重写调用类来使用proxy.
需要注意的是,如果一个anchored类被在远端执行的movable类所调用,后者同样需要前者的代理类.
由于只有根据运行时信息才能最终决定movable类的本地/远程执行以提高应用整体性能,因此我们必须对所有的被调用类生成相应的代理,并重写调用类来使用这些代理,除非调用类和被调用类都是anchored的情况.
在本文所提出的方法中,一个proxy与其被代理的应用类在外部表现及功能上完全一致.
划分后的应用类Anchored类(执行位置固定)Movable类(执行位置可变)+a2.
通过自动程序重构,使Movable类可按需远程执行Java字节码Java应用1.
划分应用类的类别abbccddeeffgghhii重构后的应用类Proxy(代理)3.
识别需要作为一个整体而远程执行的应用类集合聚类后的应用类Anchored类簇Movable类簇4.
应用类封装重构后的应用+可按需远程执行的软件制品张颖等:一种支持Java应用中计算按需远程执行的方法1717也就是说,这两个类继承了同样的父类,实现了同样的业务接口,具有同样的方法签名.
这样,才能使那些原本使用被代理类的应用类在使用proxy时不能感觉到差别.
在转换过程中,还需要处理Java语言的特性,比如静态类、内部类、数组等.
对转换的进一步说明将在第3节中展开.
(3)应用类聚类.
为了使计算远程执行能够真正提高应用的性能,我们必须避免频繁网络调用所带来的负面影响.
因为网络调用通常极为耗时,若过于频繁则反而会影响应用性能的提高.
正因如此,我们需要把相互间调用频繁的类作为一个整体在必要时放到远端执行.
倘若在应用运行才去发现应用类间的调用关系,则通常会带来巨大的开销.
因此,本步骤的目的就是要简化对应用中哪些计算需要被真正远程执行的运行时决策.
我们基于应用类聚类的方法来实现这种简化.
例如,通过聚类我们发现类X和N调用频繁.
在运行时,我们可以只监控X的执行轨迹来决定是否需要将X和N一起放到远端执行.
这样做不但可以避免X和N被分到网络两端时所需要进行的频繁的跨网络互操作,而且可以简化运行时X和N之间关系的分析以及对N的监控,从而降低开销.
(4)应用类封装.
DPartner的输入是一个给定的Java应用(如EJB应用)的组成字节码文件以及相应的资源文件,如图像文件、XML配置文件等.
在经历了以上步骤之后,DPartner的输出包含两类制品:一个是转换后封装为原始应用格式的应用,比如EJB应用的ear/jar/war.
该应用留在原网络节点运行;另一类是原始应用中那些转换后的movable类,代理类等所组成的一个可在远程网络节点部署执行的软件制品(集合).
该制品的封装格式与原始输入应用的格式相关.
比如,对于EJB应用,这第2类制品是多个EJBBean的jar文件.
2实例图3展示了一个可将计算按需远程执行的Java应用的运行时系统结构.
该应用包含了6个类,名字分别为a~i.
通过步骤1,DPartner发现类b和g都是anchored类,必须留在原网络节点上执行.
其他类都是movable类,它们既可以在原网络节点上执行,又可以在新增的远程网络节点上执行.
通过步骤2,每一个应用类都生成了对应的proxy类,并且应用类间的调用都通过proxy和endpoint来完成.
步骤3中,DPartner发现a,c,d,e和f是关系紧密的类,因此它们被聚类在一起,以备在必要时作为一个整体运行在远端.
步骤4中,DPartner将所有的movable类型的应用类、代理以及endpoint封装为可在远端节点部署执行的软件制品,如EJBjar文件(集合);该制品允许有多个副本运行在不同的网络节点上,以支持本方法所提出的通过计算远程执行来实现的对资源的占有.
同样,DPartner会将全部应用类、它们的代理以及endpoint都按照原有应用格式进行封装,比如封装为EJB的jar文件和Servlet的war文件.
转换后的应用仍放在原网络节点上进行,不同之处在于,转换后应用中,movable类中的计算可以根据需要而调用在远端的对应movable类执行或是直接在本地执行.
Fig.
3RuntimearchitectureofaJavaapplicationthatcancarryoutcomputationremotelyon-demand图3可将计算按需远程执行的Java应用的运行时系统结构在运行时,endpoint若预测到应用类d远程执行时可以提高应用性能,则会首先激活在远端的d,并且把本地d的状态通过endpoint注入到远端的d,实现状态同步,接着将本地的d停用.
此后,d的proxy将会通过endpoint把对原节点d的调用请求转发到远端的d上执行.
由于d,c,e和f在第3步时已经被聚类为一个逻辑整体,因此中间件(如JEE应用服务器)acdefbhgiacdefbhgi进程运行时平台(如JVM)重构后的应用计算可按需远程执行的软件制品本地节点远程节点网络中间件(如JEE应用服务器)进程运行时平台(如JVM)Endpoint(端点)代理类实例被激活应用类实例被激活1718JournalofSoftware软件学报Vol.
24,No.
8,August2013当d被转移到远端执行时,该聚类中的其他类也跟着被移到远端执行,以减少频繁的跨网络调用.
该过程也一样要经历激活、状态同步、停用等阶段,因此我们可以从图中看到,在原节点,a,c,d,e和f的proxy在起作用,而这些类中计算的真正执行是在远端的网络节点上.
当网络条件不佳或是发现仅原节点的资源就足以保障应用性能时,可以通过停用在远端的a,c,d,e和f并重新激活在原节点的对应类实例来将远程执行的计算移回,以节约资源并保障应用正常运行.
所有对这些类的调用都将通过proxy和endpoint转发回原节点,从而以一种按需的方式实现了应用中计算的远程执行.
3计算按需远程执行的具体实现3.
1应用类类别划分DPartner采用自动程序静态分析来识别一个给定的Java应用类的类别.
它将符合如下两个条件之一的应用类自动归为anchored:(1)类的方法含有native关键字.
方法含有native关键字表明该类需要调用本地动态链接库才能执行,因此其计算不能被转移到远程执行.
(2)该类调用anchored系统类.
例如,对于本文的实验对象EJB应用来说,我们将用于Web处理的类如"javax.
servlet.
Servlet"认为是anchored系统类.
因为我们认为,该Web类必须留在原网络节点运行才能正确接收用户请求.
因此,任何继承该类的应用类都是anchored类.
若一个应用类不满足以上两个特征,则该类被归为movable类.
DPartner提供了一个配置文件来描述需要被anchored的应用类的名字特征.
开发者可以使用该配置文件来确定某Java应用中哪些类必须被留在原节点执行或是放到远端执行,从而使分类步骤适应于每一个特殊的Java应用,以进一步保证分类结果的正确性.
例如,"cn.
edu.
pku.
password"是一个movable类.
然而,倘若开发者基于私密性的考虑而不希望将该类被放到远端执行,则可以将其写入配置文件中,DPartner会自动将该类归为anchored类.
3.
2代理生成生成proxy所面临的最大挑战就是使得proxy和被代理的对象具有完全相同的外部表现.
例如,在应用类X的实现体中,它在调用另一个应用类N中的方法时将N造型成了N的父类NP.
倘若我们只在X中把对N的调用换成对NProxy的调用,而没有让NProxy继承NP,则转换后的造型操作会出错.
因此,DPartner所生成的proxy必须与被代理的类具有相同的程序结构.
特别地,这些proxy之间也必须与被代理的类一样维持同样的继承层次结构.
例如,如果N继承了NP,那么NProxy必须继承NPProxy.
这使得任何对N从NP所继承的实例方法或是构造函数的调用都能从NProxy转发到NPProxy,并最终转发到NP.
在Java语言中,接口被用来分离一个类的外部表现和内部功能实现.
从接口的角度来说,如果一个类及其proxy都实现了相同的接口,则这两个类是完全一样的.
因此,DPartner会自动抽取接口来表示一个类及其proxy.
例如,对于应用类N来说,DPartner会:1)抽取N的全部实例方法签名来组成一个NIntf类;2)让NIntf"继承"NPIntf接口,以方便造型操作.
NPIntf是对应N的父类NP的接口;3)让N实现NIntf接口;4)让NProxy也实现NIntf接口;5)让所有调用N的应用类都改为调用以NIntf表示的NProxy.
然而对于N中的静态方法来说,由于Java语言中不允许静态方法出现在接口中,因此,DPartner会直接使用NProxy的静态方法来进行方法调用转发.
3.
3应用类转换应用类需要经过转换才能满足按需远程执行的要求.
下面列举DPartner提供的主要转换器加以说明.
3.
3.
1字段-方法转换器一个应用类的非私有字段(如以public,protected以及空修饰符所标识的字段)可以被其他类所直接使用.
然而,若该应用类被转移到远程网络节点执行,则原本使用这些字段的类就不能正常获取它们.
为了解决这个问题,本转换器自动地为非私有字段生成对应的getter/setter方法,然后将这些字段都变成私有字段,最后将对原非私有字段的直接使用转换为通过getter/setter方法进行的调用.
此外,本转换器还为一个应用类中的私有字段自动地生成对应的getter/setter方法.
这样可以通过getter/setter方法来获取并设置一个应用类的内部状态,以便于张颖等:一种支持Java应用中计算按需远程执行的方法1719应用中计算按需转移时所需要进行的对象状态同步工作.
3.
3.
2服务对象转换器为了使一个应用类与其proxy相关联,DPartner提供了该转换器以便确认一个proxy究竟应该将方法转发到哪一个具体的应用类实例上.
其功能主要是让每一个应用类实现一个特殊的ServerObject接口中的如下两种方法:getID和getProxyForSerializing.
其中,getID会返回一个整型的数值,用于表明该应用类实例的身份.
一个Proxy对象通过该ID和一个应用类实例相关联,这样能够保证方法调用转发到正确的应用类实例上.
此外,通过ID的关联可以实现分布式垃圾回收,也就是说,当发现一个proxy被JVM回收后,可以通知其所关联的应用类实例.
该应用类实例在没有其他proxy与之相关联的情况下也可以实现回收.
getProxyForSerializing用于处理回调过程中应用类实例的序列化问题,详见第3.
5节.
3.
3.
3其他转换器除了以上关键转换器之外,DPartner还实现了若干转换器来处理Java应用中一些特殊的程序结构.
这些转换器包括:ArrayTransformer,用来使对数组的存取操作在网络同步,以保证网络两端对应数组状态的一致性;AddAnonymousConstructorTransformer,用来为一个应用类增加匿名构造函数,以方便其按需远程执行时的激活和状态同步.
其他转换器如RemoveAbstractTransformer,RemoveFinalTransformer,InnerClassTransformer,InterfaceGenerator,详见DPartner项目网站以及文献[8],这里不再赘述.
3.
4应用类聚类如前所述,若随机选择某一应用类来远程执行,虽然占有了额外的资源,但并不能保证应用整体性能的提升.
原因在于,应用中留在原网络节点的部分和远程执行的部分需要进行跨网络的交互.
若交互过于频繁,则大量的计算时间消耗在网络通信而非业务处理上,因此会导致应用性能低下.
应用类聚类的目的就是把那些相互间调用频繁的movable类作为一个逻辑单元(称为cluster),并将它们一起移动到远程网络节点执行,通过避免它们之间高额的网络调用来保障计算远程执行的有效性.
DPartner对应用类的聚类是通过程序分析建立调用关系图来实现的,并且为了弥补静态分析的不足,DPartner还基于已有研究中已证明的关于关系紧密的类之间具有语义相似性的结论[12],利用类中的变量以及方法名的文本相似度信息来校准前面建立的调用关系图,从而把那些关系真正紧密的类聚在一起.
我们为DPartner设计了一种应用类聚类算法来完成聚类任务.
本文中不再详细讨论算法实现和原理证明,可以参见文献[8].
此外,聚类信息还可以通过DPartner调用程序动态分析软件进行分析后得到,如执行相关测试用例.
DPartner会把聚类信息存储在转换后的应用制品中.
在运行时,endpoint将会使用该信息来辅助决定哪些类对应的计算应该被转移到远端执行,详见第3.
6节.
3.
5Endpoint的实现如前所述,DPartner会为转换后的应用提供一个称为endpoint的通信基础设施,用于负责应用中计算远程执行时,留在原节点上执行的部分与在新节点上执行的部分间跨网络的互操作.
从应用类X到远端的应用类N的方法调用会首先由表示为NIntf的NProxy转发到endpoint,并最终由endpoint转发到远端的N,如图4所示.
在NProxy的一个方法体中,endpoint的"invokeMethod"方法被用来实现方法调用转发.
InvokeMethod的参数如下:(1)应用类N的全名.
(2)应用类N的实例ID.
每一个proxy都拥有它所对应的被代理应用类的实例ID.
当proxy被创建时会被赋予该ID来与被代理类实例相关联.
(3)字节码级别的方法签名.
在Java字节码中,所有方法签名都表示为如图4所示的"Internalname".
(4)N的"methodM"方法执行时所需要的参数.
Endpoint可以通过以上信息来唯一定位一个N对象,并调用其methodM执行,最后返回结果.
当方法调用基于RCS(见第1.
1节)发送到网络栈来进行时,方法的参数需要被序列化才能在网络上传输.
我们要特别注意回调情况下调用对象的序列化和反序列化问题.
例如,X运行在原网络节点,N运行在新分配的远端网络节点.
X调用了N的"handleCaller(XIntf)"方法(实际上调用的是以NIntf表示的NProxy对象的handleCaller方法).
该方法中,X将自己作为参数传递到N,而后N通过传递过来的X引用来回调X的方法.
可以看到,X需要被序列化才能进行网络传递.
值得注意的是,当X在N所在的地址空间被反序列化后,整个应用会同1720JournalofSoftware软件学报Vol.
24,No.
8,August2013时存在两个ID相同的X实例,一个在原网络节点,另一个在N所在节点.
这时,如果N对其所在端的X进行了处理,则对应操作不能被转发到原节点的X,从而导致两个X之间内部状态不一致,产生运行时错误.
此外,倘若X是一个anchored类型的应用类,它本身就不能被传到远端.
因此,为了解决上述问题,当X需要被序列化时,应该序列化它的proxy.
如图5所示,endpoint会自动调用X实现的ServerObject接口中的getProxyForSerializing方法来获得一个XProxy(见第3.
3.
2节),并传给远端的N.
这样,N可以用该XProxy来完成对X的远程回调.
Fig.
4Methodforwardingchainfromproxytoendpoint图4从proxy到endpoint的方法调用转发链Fig.
5Callerde/serializationincallback-styleremotemethodinvocation图5方法调用者在回调风格的远程调用中被序列化/反序列化通过endpoint,两个应用类之间的互操作可以较为容易地实现优化.
例如,当X和N都在同一个JVM中时,endpoint会直接使用内存引用来进行方法调用转发.
这样,方法调用时就不需要经过耗时的网络栈,从而可以保障应用的性能.
此外,将对网络通信的处理集中在endpoint而不是分散在各个proxy也带来了如下3个好处:1)使得proxy尽可能地小,以方便在网络上的传输.
2)帮助实现调用者和被调用者的解耦.
若用于识别本地/远程通信的代码存在于proxy中,则X对NProxy的直接单向引用将会变成直接双向引用.
也就是说,NProxy必须知道X的具体位置才能实现N和X之间的互操作优化.
3)其他与通信相关的代码,如远程调用重试、移除分布式死锁[13]等,能够容易地加入endpoint中,从而以方法调用的截取器链的形式来保障远程通信的质量.
publicclassNProxyextendsNPProxyimplementsNIntf{publicSIntfmethodM(SIntfs,TIntft){return(SIntf)ProxyFacade.
getEndpoint().
invokeMethod("foo.
bar.
N",//remoteclassthis.
serverobjID,//classinstanceID//bytecode-levelmethodsignature"methodM(Lfoo/bar/intf/SIntf;Lfoo/bar/intf/TIntf;)Lfoo/bar/intf/SIntf;",newObject[]{s,t}//parameters);}//endmethodM}//endNProxyinvokeMethod(X,callback)handleCaller(X)XNNProxyEndpointEndpointXProxyInvokeMethod(N,handleCaller,X)getProxyForSerializing()serializedObjectStreamsendMsg()XProxyreadObjecthandleCaller(XIntf)callbackcallbacksendMsg()receiveMsg()receiveMsg()张颖等:一种支持Java应用中计算按需远程执行的方法17213.
6计算按需远程执行的决策如前所述,endpoint会在运行时决定应用中的计算是否需要远程执行.
从整个应用中计算执行的分布角度来看,此项决策的实质就是决定应用中哪部分计算需要执行在哪个节点才能保障应用性能并提高资源利用率.
因此,在不考虑应用自身优化的情况下,该项决策转换为求解应用类放在哪个节点才能充分且足够地享有所需的资源以保障执行效率,并且尽量减少与其他应用类之间由于进行耗时的跨网络调用而带来的执行效率损失.
我们采用更形式化的方法来描述以上问题.
在以下的描述中,N代表自然数,R代表实数.
3.
6.
1应用结构我们设应用C={c1,c2,…,cn},表示应用由n个类组成.
需要注意的是,这里的ck可以表示为ck={ck1,ck2,…,ckm}这m个类,其属性为对应各个类的属性和.
这样做的目的是利用第3.
4节已经计算出的类聚类信息将多个关系紧密的类看成是一个类参与计算,以减小问题域的规模,加快求解过程.
应用结构的相关函数参数如下:交互频率(frequencyofinteraction,简称foi):foi:C*C→R;传输数据量大小(transmissiondatasize,简称tds):tds:C*C→R;工作负载(workload,简称wl):wl:C→N;内存消耗(memoryconsumption,简称mc):mc:C→N.
3.
6.
2节点配置给定节点集合VM={vm1,vm2,…,vmk},表示有k个节点(虚拟机VM),相关函数参数如下:处理机能力(processingspeed,简称ps):ps:VM→N;网络带宽(networkbandwidth,简称nb):nb:VM*VM→N;网络延迟(networkdelay,简称nd):nd:VM*VM→N;内存拥有量(memorypossessed,简称mp):mp:VM→N.
3.
6.
3部署结构应用中计算的按需远程执行实质上就是将应用类部署在网络节点上被并调用执行的过程.
可以用下式来表示:D={d|d:C→VM},其中,d是将应用类C部署在节点VM上的一种拓扑结构.
D1={c∈C|d(c)=vm}表示确定了部署结构以后,可明确知道一个节点上执行的应用类.
3.
6.
4约束条件合理的部署结构需要满足一定的约束条件,针对本文的工作,我们给出如下两个约束条件:(a)资源约束,这里特定为内存资源约束:θmem:D→{true,false},即1()memcDvmdvmVMmccmpvmθ∈(b)位置约束:loc:D→{true,false},即loc(d)=c1,c2∈C:(colloc(c1,c2)=1)→d(c1)=d(c2);(colloc(c1,c2)≠1)→d(c1)≠d(c2),其中,colloc(c1,c2)=1表示应用类c1和c2必须位于相同的位置;否则,必须位于不同的位置.
我们在第3.
1节介绍的应用类分类信息可以作为colloc函数取值的参考输入.
3.
6.
5目标如前所述,计算按需远程执行的目标是要在充分利用资源的情况下,尽量提高应用的性能.
也就是说,要使Q:D→R尽可能地大,即求解使应用质量属性Q尽可能大的一种应用部署结构.
本文所关注的Q为应用的性能与资源消耗的比值:Q=P/Res.
其中,性能P可被看作应用类的工作负载被处理的效率以及网络开销组成的一个函数值,表示如下:P=α*Pworkload+β*Pnetwork,α,β∈(0,1),α+β=1(1)11()1()()jworkloadkjjcDvmPwlcpsvm=∈=∑∑(2)1722JournalofSoftware软件学报Vol.
24,No.
8,August201311111networknnnnijijijijijijijPfoicctdsccfoiccnddcdcnbdcdc=====**+∑∑∑∑(3)而资源则表示为1()()kjjjRespsvmmpvm==*∑(4)因此,最终的目标是要让公式(1)与公式(4)的比值最大化.
可以看到:公式(2)本质上是一个背包问题[14],在复杂性上是NP难的;公式(3)本质上是一个图分割求最小割集问题[15],当节点数目大于3时,也是一个NP难问题.
然而,这两个问题目前已有很多优化的近似解法,endpoint缺省采用其中经典且较快的解法——动态规划以及MinCut[15]来进行求解.
考虑到还可能存在如贪心法等其他多种近似求解方法,因此,endpoint提供了一个Q=P/Res值求解扩展机制,可以将运行时得到应用和节点的相关参数信息作为其他方法的输入,取得返回结果D={d|d:C→VM},以决定最终应用中计算远程执行对应的部署方案,从而完成决策过程.
Endpoint也允许由管理员给出的高层命令(如通过JMX[16]命令)来实施计算转移,以提供灵活性并增强应用对环境的适应能力.
4实验在本节,我们要验证计算可按需远程执行的应用在性能上的提升和对资源的有效利用.
实验采用了单机应用和分布式应用.
文献[8]中已经详细介绍了DPartner如何将单机应用通过自动字节码重构而转换为可按需远程执行的应用.
接下来,本文主要介绍DPartner在分布式应用RUBiS[17]上的实验.
RUBiS是美国RiceUniversity所研发的EJB基准测试集.
它模拟了类似于eBay[18]的商品买卖竞标系统.
该应用包含17个ejb以及对应的若干servlet等Web界面显示类.
它的测试驱动器模拟用户浏览Web界面的操作,从而使ejb中计算得以执行.
该测试驱动器所产生的工作负载主要由如下3个参数来控制:requesttransitiontable,clientnumber和sessionruntime.
RUBiS的read-write类型的requesttransitiontable表示模拟出的客户访问请求除了进行读操作,如浏览商品项目、浏览别人对该商品的评价等以外,还要进行写操作,如添加商品信息、对商品评价等,从而会改变数据库中的内容.
Clientnumber表示同时有多少用户来访问RUBiS应用.
访问量越大,系统的负载也就越大.
Sessionruntime表示一个用户访问RUBiS应用的时长.
时间越长,该应用在该时间段内所做的操作就越多,因此系统的累积负载量也就越大.
RUBiS应用虽然是分布式应用,但其中的计算并非能按需远程执行.
在原有的RUBiS应用中,servlet对ejb的调用以及ejb之间的调用都是通过namingservice来完成的.
例如,SB_AboutMeBean这个SessionBean用于显示注册用户的信息.
它在执行操作之前必须调用SB_AuthBean来完成对输入的用户名和密码的验证工作.
然而,SB_AboutMeBean却直接使用了newInitialContext()语句来从本地JVM中获得EJB的上下文,进而用来查找SB_AuthBean.
这也就意味着,只有当SB_AuthBean和SB_AboutMeBean在同一个JVM中执行时,从该上下文中对SB_AuthBean的Lookup操作才会成功.
倘若SB_AuthBean被放到网络上的其他JVM中,在SB_AboutMeBean所在的JVM中就没有该EJB的信息,从而会导致后续Lookup的失效.
因此我们可以看到,当SB_AuthBean改变了部署的网络节点位置时,调用它的SB_AboutMeBean也需要进行修改才能适应这种变化,比如需要修改为Propertiesenv=newProperties();env.
setProperty(Context.
INITIAL_CONTEXT_FACTORY,"org.
ow2.
carol.
jndi.
spi.
JRMPContextWrapperFactory");env.
setProperty(Context.
PROVIDER_URL,"rmi://192.
168.
0.
189:1099");//192.
168.
0.
189表示SB_AuthBean目前所在的VM的地址env.
put(Context.
URL_PKG_PREFIXES,"org.
objectweb.
jonas.
naming");InitialContextctx=newInitialContext(env);这样,才能从所获的InitialContext查找到SB_AuthBean并加以使用.
然而如前所述,由于开发者很难预料到应用张颖等:一种支持Java应用中计算按需远程执行的方法1723对资源的准确使用,因此所开发出的EJB应用中的本地/远程调用关系固定不变.
倘若由于节点192.
168.
0.
189宕机而将SB_AuthBean放到另一个网络节点上执行,则对应的SB_AboutMeBean又需要改变.
因此,原有的RUBiS应用虽然是分布式应用,然而却不能做到对计算资源的按需占有和使用.
此外,一个EJB应用中除了EJB类以外,还有很多普通的POJO(plainoldJavaobject)类,如RUBiS应用中的edu.
rice.
rubis.
beans.
TimeManagement类.
这些类通常会被EJB类在处理业务请求时作为辅助类被调用.
也就是说,EJB和这些POJO类之间形成了第1.
1节所示的直接内存调用结构,当这些类也亟需计算资源而无法满足时,也需要实施计算转移.
然而,已有的结构不允许这些类脱离调用它的EJB而被转移到其他节点执行.
4.
1DPartner的可用性如图2所示,DPartner通过字节码级别的程序转换而自动将原始RUBiS重构为计算可按需远程执行的RUBiS.
在RUBiS所拥有的59个类中,所有的20个servlet类由于继承了被DPartner认为是anchored类的系统类:javax.
servlet.
http.
HttpServlet而被自动归为anchored类.
在其他类中,由于edu.
rice.
rubis.
servlets.
ServletPrinter使用到了一些本地节点才有的文件系统资源,因此也被归为anchored类.
剩下的38个类(普通POJO类以及EJB的Bean类)都被视作movable类型的类.
经过自动聚类发现,edu.
rice.
rubis.
servlets.
Config被servlet类频繁调用,因此,它和servlet聚类在一起,始终留在原网络节点执行.
转换后的各个ejb被封装成可以独立部署的EJBjar文件,其中包含了转换后的EJB实现体Bean文件、interface文件、proxy文件等.
Endpoint也被封装为一个EJBjar文件以部署在JOnAS[19]JEE应用服务器中.
转换前后的RUBiS相关信息对比见表1.
可以看到,转换后,RUBiS的大小会有所增加,原因在于,DPartner对字节码进行了重写,生成了接口、proxy等新的类,并且增加了endpoint等基础设施代码.
我们也可以看到,转换时间开销大概在2min.
由于转换发生在应用运行前,因此开销是可以接受的.
Table1RefactoringperformanceofDPartneronRUBiS表1DPartner对RUBiS进行重构的性能度量RUBiS原始应用对应的ear文件的大小(KB)596重构后应用对应的ear,jar,war文件的大小(KB)1437大小增长(KB)841Movable类型的应用类的数量和百分比38(38/59=64.
4%)重构时间开销(s)112.
3转换后,在RUBiS应用中,servlet对ejb的调用以及ejb之间的调用实现了按需远程化.
例如,如图3所示,servletB需要调用ejbE所提供的功能.
Endpoint通过监控并分析前一段时间内B和E之间的调用序列信息,包括消息收发时间、数据量、成功次数等,得到历史上B和E执行的情况概览(profile).
若通过分析预测发现B和E在同一个JVM中执行就能维持下一段时间的性能,就直接调用无参数的newInitialContext()来使B获得对本地E的引用,从而直接调用E;而当发现本地资源难以支持E执行时,endpoint会向运行环境中的虚拟机管理器发送一个启动特定资源量的新虚拟机的命令.
该虚拟机已经部署好了转换后RUBiS应用中的ejb副本.
接着,本地的endpoint使用带参数的newInitialContext(env)来获得新虚拟机上的ebjE对应的上下文,从而实现B对在远端执行的E的调用.
运行在本地以及远端的E的激活、状态同步、停用等操作也由endpoint负责.
需要注意的是,在远程调用时,InitialContext参数中E所在的URL地址信息是由虚拟机管理器返回的结果来设定的.
此外,endpoint也提供了配置文件以及JMX服务来实现相关参数的动态调整,以保障应用中计算按需远程执行的灵活性.
当通过监控发现,随着应用负载量的减少,系统资源变得相对过剩时,servlet所在的本地endpoint就会逐渐回收E的执行.
也就是说,该endpoint会在其所在虚拟机启动本地E,并进行本地E和远程E之间的状态同步工作.
然后,该endpoint将B对E的请求转发回本地的E来处理,即,使得B又改为使用无参数的newInitialContext()来获得对本地E的引用.
接着,本地的endpoint向远端的endpoint发送停止远端E的请求.
若远端的E没有被其他类所调用,它就会进入钝化阶段,释放资源.
若远端已没有RUBiS应用中的计算在执行,则一段1724JournalofSoftware软件学报Vol.
24,No.
8,August2013时间后,其endpoint就会向虚拟机管理器发送停止自身所在虚拟机运行的请求,以在保障RUBiS应用性能的前提下实现对资源的节省.
如前所述,DPartner在对RUBiS进行静态程序分析的基础上,还通过执行测试用例来预先发现RUBiS中究竟是哪个EJB最耗资源,并且发现Servlet和EJB之间调用的紧密程度,以在运行时加快应用中计算按需远程执行的决策.
在读写情况下,RUBiS中的SearchItemsByCategoryBean的实例所占的计算资源最大,且计算最耗时,并常与BrowseRegionsBean,BrowseCategoriesBean,SearchItemsByRegionBean,ViewItemBean,ViewUserInfoBean以及StoreBidBean一起使用.
这是因为测试用例所模拟的用户在读写情况下,通常会根据自己所在的位置(BrowseRegionsBean)来查看商品的种类(BrowseCategoriesBean)或搜索商品(SearchItemsByCategoryBean/SearchItemsByRegionBean),查看商品的详细信息(ViewItemBean),在决定要竞买商品时,先要查看商品的卖家(ViewUserInfoBean),最后下单子竞买商品(StoreBidBean).
因此,上述几个EJB会被DPartner聚类在一起,在必要时被一起转移到或留在拥有较大计算资源的节点上运行.
4.
2转换后RUBiS应用中计算的按需远程执行我们使用北京大学自主研发的网构软件测试床InternetwareTestbed[20]中的虚拟机作为实验平台,一共使用了5台虚拟机节点,见表2.
其中,VMtestdriver用来放置RUBiS的测试驱动器;VMapache放置Apache服务器,用来将来自RUBiStestdriver的访问请求转发给VMjonas1或VMjonas2,后者根据需要用来放置RUBiS的servlet和ejb;VMdb用来放置MySQL数据库,其中包含有RUBiS应用所需的4万条商品信息以及10万个注册用户信息.
这5台虚拟机的操作系统版本都是Ubuntu8.
04server,并由100M带宽的网络相连.
需要注意的是,VMjonas1和VMjonas2的虚拟CPU数和内存拥有量都小于其他节点,只有这样,才能在接下来的实验中保障RUBiS应用的性能由其自身所获得的计算资源量来决定.
换句话说,我们这样做的目的是要避免testdriver,Apache,MySQL早于RUBiS面临到计算资源不足而成为瓶颈,避免导致影响测试准确性的情况发生.
Table2VMsintheexperiment表2实验所用VM节点CPU(vCPU)内存(MB)软件系统配置VMtestdriver21024JDK1.
6,RUBiStestdirverVMapache21024Apache/2.
2.
8(Ubuntu)VMjonas11384JDK1.
6;JOnASJEEServerv5.
2.
0VMjonas21384JDK1.
6;JOnASJEEServerv5.
2.
0VMdb21024Mysql-5.
0.
51a-3ubuntu5.
7-log(Ubuntu)实验的目的是要对比原始RUBiS和转换后的RUBiS在性能上的差异(以吞吐量和响应时间为指标),以验证计算按需远程执行的有效性.
实验中,RUBiS的测试驱动器的参数都设为一样:采用读写模式的requesttransitiontable;clientnumber从100逐渐增大到1000;每一组clientnumber的sessionruntime为10min.
我们设计了如表3所示的对比实验场景.
在图6中展示了表3场景下RUBiS应用的吞吐量和响应时间的对比结果.
从图6中我们可以得到如下3个主要结论:(1)计算资源受限是影响应用性能提升的重要因素.
与其他场景相比,Local场景下RUBiS应用所占有的资源是最少的,其性能总体上也是最差的.
当clientnumber超过600时,由于计算资源受限,Local中RUBiS的性能反而急剧下降.
当clientnumber增大到800以上时,整个RUBiS应用甚至出现了崩溃现象.
(2)计算资源应该按需使用以提高利用率.
我们也可以发现,Local场景下RUBiS性能并不总是不如其他场景.
如当clientnumber在350以下时,其测我们将VMjonas1以及VMjonas2的内存都设为512及以上容量时,整个RUBiS应用的性能瓶颈出现在MySQL数据库上.
因此,这里我们将这两个VM的内存值设定得比较小,使其成为真正的系统性能瓶颈.
张颖等:一种支持Java应用中计算按需远程执行的方法1725得的吞吐量甚至是最高的.
这反映了其他场景中的RUBiS虽然占有了更多的计算资源,但没有充分利用,实际上产生了浪费.
对于FixedCluster以及FixedOffload,造成的浪费则是最大的,因为没有必要在用户请求负载量不大的情况下就比Local场景多消耗一个VMjonas2节点的资源.
Table3Testingscenarios表3实验场景实验场景系统结构描述Local原始RUBiS被完全部署在VMjonas1.
也就是说,所有的servlet被封装成了war文件,所有的ejb都被封装为了jar文件.
然后,这些文件都被部署在VMjonas1.
FixedCluster原始RUBiS的两个副本被分别部署在VMjonas1和VMjonas2上,它们一起形成了RUBiS集群.
Apache服务器负责将客户请求按照轮询(round-robin)的方式转发给这两个RUBiS所组成的集群.
DynamicCluster原始RUBiS的两个副本被分别部署在了VMjonas1和VMjonas2上,它们形成了RUBiS集群.
Apache服务器负责将客户请求转发给VMjonas1所在的RUBiS.
当客户请求量增大到400时,VMjonas2以及其上运行的RUBiS被启动.
在此之后,Apache负责将客户请求按照轮询(round-robin)的方式发送给这两个RUBiS所组成的集群.
FixedOffload原始RUBiS中的ejb被分成两部分,分别运行在VMjonas1和VMjonas2上.
在VMjonas2的ejb是ViewUserInfoBean和SearchItemsByCategoryBean.
其余ejb以及servlets都运行在VMjonas1.
Apache服务器将客户请求转发给VMjonas1.
当servlets收到请求后,它会根据请求内容而调用在不同VM上的ejb.
On-DemandOffload重构后的RUBiS被首先部署并激活运行在VMjonas1上.
当RUBiS应用系统未能达到既定性能目标时,其中的一些ejb就被自动转移到一个新分配的VM上运行.
该VM已事先部署上了转换后RUBiS的ejb,因而ejb转移执行也就是在VMjonas1上停止执行某个ejb而在新分配的VM上激活执行对应的ejb.
在本实验中,这个新分配的VM是VMjonas2.
Fig.
6ThroughputsandresponsetimeofRUBiSinthefiveexperimentalscenarios图65种场景下RUBiS的吞吐量和响应时间VMtestdriverVMApacheVMjonas1VMdbVMtestdriverVMApacheVMjonas1VMdbVMjonas2VMtestdriverVMApacheVMjonas1VMdbVMjonas2VMtestdriverVMApacheVMjonas1VMdbVMjonas2VMtestdriverVMApacheVMjonas1VMdbVMjonas2Throughputinsuccessful(request/min)LocalFixedClusterDynamicClusterFixedOffloadOn-DemandOffload2000180016001400120010002004006008001000NumberofclientsRequestresponsetime(s)LocalFixedClusterDynamicClusterFixedOffloadOn-DemandOffload22201816141210864202004006008001000Numberofclients1726JournalofSoftware软件学报Vol.
24,No.
8,August2013对比FixedCluster和FixedOffload这两个场景下RUBiS的性能可以看到,虽然RUBiS占有的资源量是一样的,但FixedCluster对应的性能却相对较差.
其原因在于,FixedOffload中的VMjonas2只承担RUBiS中的ViewUserInfoBean和SearchItemsByCategoryBean这两个最亟需资源的ejb运行,而FixedCluster中的VMjonas2却要承担了整个RUBiS副本的运行,造成了资源竞争,反而影响了整体性能的提高.
同时我们还需要注意,在FixedOffload场景中,Servlet对ViewUserInfoBean和SearchItemsByCategoryBean这两个EJB的远程调用是固定不变的,这就导致了即便是存在这两个ejb的副本运行在servlet所属的JOnAS应用服务器中,serlvet也不会调用它们,即也不会进行本地调用.
也就是说,当用户请求负载较小(小于350)而本地资源充足时,这两个ejb的计算也还要在远端节点上执行,造成了浪费.
对比DynamicCluster和FixedOffload这两个场景可以看到,由于动态集群(DynamicCluster)只在需要时(这里为clientnumber大于400时)才启动新的副本以承载用户请求,因此当负载较小而本地资源充足时,本实验中的DynamicCluster就等同于Local,而这时DynamicCluster所得到的性能要优于FixedOffload,且占用的资源要少.
而当用户请求负载量增大时,DynamicCluster等同于FixedCluster.
根据前面所分析的资源竞争的原因可以看到,这时DynamicCluster虽然与FixedOffload占用等量的计算资源,然而所得到的性能却不如FixedOffload.
综合上述分析可以看到,本文所提出的通过计算按需远程执行来保障应用性能并提高资源利用率是必要的,但原始的RUBiS应用在各种场景下(即Local,FixedCluster,DynamicCluster以及FixedOffload)都难以达到此目标,因此我们接下来通过On-DemandOffload场景来验证转换后的RUBiS在实现计算可按需远程执行上的有效性.
(3)On-DemandOffload能够有效地保障应用性能并提高资源利用率.
经DPartner转换后的RUBiS应用中计算按需远程执行的场景为On-DemandOffload.
在该场景中,我们参考图6的测试结果,为RUBiS设定了相应的性能目标:在clientnumber小于350的情况下,其吞吐量以Local中的吞吐量为基准,上下浮动50requests/s;当clientnumber超过350时,其吞吐量以DynamicCluster的吞吐量为基准,不设上限,但下限设为DynamicCluster吞吐量+(100~200)request/s(同时参考了FixedOffload的吞吐量).
分别以Local和DynamicCluster作为基准性能目标的原因在于,我们想验证On-DemandOffload场景中的RUBiS是否能通过按需使用资源来保障性能,并且验证其是否在拥有相同资源的情况能够达到更优的性能.
我们将性能目标写入转换后RUBiS的endpoint配置文档中.
在运行时,endpoint会监控RUBiS的servlet的执行,从而验证目标是否达到.
若现有计算资源不能支持目标实现,则endpoint会实施计算转移,即选择RUBiS中的一部分ejb,将其计算转移到新申请的VM上,并不断调整在新VM上执行的EJB,从而实现在保障应用性能的前提下,充分地利用计算资源.
在实验过程中,VMjonas1和VMjonas2上运行的ejb见表4.
从图6和表4中我们可以看到:当clientnumber小于400时,VMjonas1所拥有的计算资源足以支撑RUBiS达到所设定的性能目标,因此在此阶段,RUBiS中所有的servlets和ejbs都留在VMjonas1上执行;当clientnumber增大到400时,情况却发生了变化,现有的VMjonas1的资源难以支撑RUBiS达到设定的目标,因此在endpoint的预测和控制下,整个应用获得了一台新的虚拟机VMjonas2,RUBiS开始将自己的一部分ejb转移到这台虚拟机上执行.
随着clientnumber的不断增大,转移到VMjonas2上执行的ejb也越来越多.
刚开始只有Remote1={StoreCommentBean,PutCommentBean,BuyNowBean}这3个ejb;待clientnumber增大到800以上时,已有Remote3对应的9个ejb在VMjonas2上执行.
正如第3.
6节所述,endpoint会计算出如何分配RUBiS的ejb才能最大限度地提高Q=性能/资源的比值.
这里,由于为了减少计算转移时因状态同步引起的网络通信开销,因此endpoint选择留下那些对计算资源消耗较大的ejb运行在VMjonas1上,而将一些不很亟需资源但仍然占有并竞争资源的ejb(如,Remote1中所包含的ejb)转移到VMjonas2来执行,servlets对这些ejbs的调用也由本地调用自动变为远程调用.
如第4.
1节所分析的,不难从表4中看到,资源消耗最大的SearchItemsByCategoryBean留在VMjonas1上,与它在一起的还有BrowseCategoriesBean,BrowseRegionsBean,SearchItemsByRegionBean,ViewItemBean,ViewUserInfoBean以及StoreBidBean等ejb.
原因在于这些ejb常常被一起调用(见第4.
1节的分析),而且资源消耗都很大,倘若只将其中某些ejb转移到远端执行,张颖等:一种支持Java应用中计算按需远程执行的方法1727则会增加网络通信开销,导致client在模拟RUBiS的购物操作过程中,在sessionstate转换的时延增大,降低了应用的整体性能.
Table4Ejbsthatareexecutedremotelyduringthe"On-DemandOffload"experimentalscenario表4On-DemandOffload实验场景下远程执行的ejb客户数量在VMjonas1上运行的EJB在VMjonas2上运行的EJB资源量相同的参考实验场景性能提升(%)100~400全部servlet和ejbLocalDynamicCluster2.
4400~500全部servlet以及除了Remote1集合以外的ejbRemote1={StoreCommentBean,PutCommentBean,BuyNowBean}FixedOffload1.
3DynamicCluster3.
2500~600全部servlets以及除了Remote2集合以外的ejbRemote2=Remote1+{BuyNowBeanStoreBuyNowBean,AboutMe}FixedOffload2.
7DynamicCluster5.
3600~700全部servlets以及除了Remote2集合以外的ejbRemote2FixedOffload2.
1DynamicCluster10.
1700~800全部servlets以及除了Remote3集合以外的ejbRemote3=Remote2+{RegisterUserBean,RegisterItemBean,ViewBidHistoryBean}FixedOffload6.
8DynamicCluster11.
3800~900全部servlets以及除了Remote3集合以外的ejbRemote3FixedOffload7.
4DynamicCluster10.
7900~1000全部servlets以及除了Remote3集合以外的ejbRemote3FixedOffload4.
6当clientnumber小于400时,On-DemandOffload场景下RUBiS的执行等同于Local场景下的执行.
其性能与FixedCluster以及FixedOffload场景中RUBiS的性能相比平均要高5.
2%,且后两个场景中RUBiS还占用了更多的资源,即,多占用了VMjonas2;当clientnumber增大到400以上时,On-DemandOffload相对于占用等量资源的DynamicCluster和FixedOffload来说,性能仍然要高.
比如,当clientnumber为900时,On-DemandOffload场景下RUBiS的性能要比在DynamicCluster场景下高出11.
3%,比FixedOffload场景也要高出7.
4%.
这充分说明了转换后的RUBiS在保障应用性能的同时提高了计算资源利用率.
通过以上的一系列实验,我们可以得到如下主要结论:(1)通过计算按需远程执行来占用充足且足够的计算资源是保障应用性能并节约成本的重要手段;(2)DPartner能够有效实现应用中计算的按需远程执行,并且经其转换后的应用可以在保障性能的前提下提高对资源的利用率,也更能适应复杂多变的计算环境.
因此,实现计算按需远程执行可以作为一种对传统的粗粒度cluster进行精细优化的重要方法.
5相关工作计算的远程执行是近年来较为热门的研究之一,并且随着云计算的兴起,该研究也进入了一个新的发展时期[21].
究其原因,在Internet环境下,网络上单节点(比如云中的一台虚拟机)所拥有的资源总是有限的,而多个网络节点所组成的整体却拥有大量的资源.
实现计算的远程执行,正是一种通过对远程资源的占有来解决本地资源不足的有效手段.
基于分布式中间件或分布式应用开发框架实现远程执行的方式,要求开发者必须按照框架所规定的编程模型进行开发,并且只适用于新的应用.
此外,由于开发者难以预料到应用对资源的使用,因此所开发出的应用的远程/本地调用方式也固定不变,导致应用仍然难以实现按需的计算远程执行.
即便是采用集群的方法来实现计算转移,比如使用JOnASJEE应用服务器所提供的CMI(clustermethodinvocation)服务[22],按照Round-Robin等方式将对某个ejb的调用转发到拥有该ejb副本的JOnAS集群中的某一个成员来处理,开发者仍然需要编写与CMI相关的代码并进行相应的配置才能达到目标.
并且,现有的按照Round-Robin实现的远程调用方案也难以达到按需使用资源的目的.
一些计算远程执行的工作是基于DSM(分布式共享内存系统)来实现的,DSM可被看成是一类特殊的分布式中间件,提供一个本地和远程所共享的内存存储环境.
COMET[23]是基于DSM来实现计算远程执行的代表性工作之一,它修改了移动应用的运行支撑虚拟机,使其与服务器虚拟机一起联合提供对于移动应用来说一致的共享内存,促使应用中的计算任务可按需在本地或远程服务器执行.
然而,由于修改环境1728JournalofSoftware软件学报Vol.
24,No.
8,August2013来构造DSM的代价很大,该类工作也仅限于特定的DSM环境,难以实用化.
通过自动程序转换来实现计算远程执行的方法不但可用于新的应用,也可以用于遗产应用.
并且,转换的自动执行也能有效减少人力开销,因而逐渐成为一个极具潜力的研究方向.
Goign[24]是最早通过自动程序转换来将给定的WindowsCOM应用中的计算远程执行的工作之一.
由于COM构件间的方法调用必须经过虚函数表(virtualfunctiontable,简称VTBL)来查找对应方法,因而Coign通过修改指向VTBL的指针位置以及VTBL中每一项所指向的方法的位置将对某一方法的调用截取后,转发给远端COM构件执行.
JavaParty[25]是针对Java应用来实现其计算远程执行的最早的工作,它在应用源代码上完成程序转换任务,应用最终被转换成符合JavaRMI的应用.
JavaParty在实施转换前需要开发者在应用源代码中对他们认为需要远程执行的类上标注"Remote"关键字.
那些标注后的应用类在转换后增加了java.
rmi.
Remote接口等RMI所规定程序元素,并且实现了向NamingService注册的工作,从而得以在RMI平台的支撑下远程执行.
J-Orchestra[9]也是通过自动程序转换而将给定的Java应用转换为符合RMI规范的应用.
与JavaParty不同的是,J-Orchestra所实施的转换是在Java的字节码层次上进行的.
在转换之前,J-Orchestra给出了一个GUI界面,将该应用中的类(字节码文件)以列表的形式展现出来,然后由开发者指定这些类中有哪些需要被移动到远端网络节点执行.
而后,这些类将被RMI化.
应用留在原节点的部分通过RMIstub来调用那些移动到远端执行的类.
与以上的研究工作相比,本文所提出的方法以及DPartner系统实现具有两个最大的特色:(1)转换过程对开发者保持透明.
DPartner不需要开发者在应用源代码上进行标注或是在字节码中进行选择,而会通过自动程序分析来判断哪些应用类是否适合于远程执行,并自动完成转换工作,极大地降低了转换过程给开发者带来的负担.
(2)转换后所得应用中的计算是可以按需远程执行的.
在如JavaParty,J-Orchestra等已有工作中,转换后的应用的本地/远程调用结构固定不变,这导致应用难以适应变化的环境,降低了转换方法的实用性.
6结束语计算的按需远程执行,是从软件应用自身角度实现对资源按需占有,以保障性能并提高资源利用率的重要手段.
本文给出一种通过自动程序转换来实现Java应用中计算按需远程执行的方法.
该方法提出了一种支持计算按需远程执行的程序结构,并实现了名为DPartner的自动程序转换系统,在字节码层次上将原始Java应用转换为符合该程序结构的应用.
在转换过程中,处理了正确性和有效性等带来的技术挑战.
本文以及前驱工作还在Java单机应用和分布式应用上进行了一系列实验.
结果表明了DPartner在实现应用中计算按需远程执行上的有效性,并证明了转换后应用在性能上的提升以及对资源的充分使用.
未来的工作是继续改进DPartner并将用更多真实的应用来对其进一步验证.
DPartner可以在http://code.
google.
com/p/dpartner/上访问到.
致谢在此,我们向对本文的工作给予支持和建议的同行,尤其是北京大学信息科学技术学院软件研究所网构软件小组的老师和同学表示感谢.
References:[1]YangFQ,MeiH,LüJ,JinZ.
Somediscussiononthedevelopmentofsoftwaretechnology.
ActaElectronicaSinica,2002,30(12A):19011906(inChinesewithEnglishabstract).
[2]ZhangY,HuangG,LiuXZ,MeiH.
Integratingresourceconsumptionandallocationforinfrastructureresourceson-demand.
In:Proc.
ofthe3rdIEEEInt'lConf.
onCloudComputing(Cloud).
IEEEPress,2010.
7582.
[doi:10.
1109/CLOUD.
2010.
11][3]YangFQ,LüJ,MeiH.
Technicalframeworkforinternetware:Anarchitecturecentricapproach.
ScienceinChinaSeriesE:TechnologicalSciences,2008,38(6):818828(inChinesewithEnglishabstract).
[doi:10.
1007/s11432-008-0051-z][4]MeiH,HuangG,LanL,LiJG.
Asoftwarearchitecturecentricself-adaptationapproachforinternetware.
ScienceinChinaSeriesE:TechnologicalSciences,2008,38(6):901920(inChinesewithEnglishabstract).
[doi:10.
1007/s11432-008-0052-y]张颖等:一种支持Java应用中计算按需远程执行的方法1729[5]WengCL,LiML,WangZG,LuXD.
Automaticperformancetuningforthevirtualizedclustersystem.
In:Proc.
ofthe29thIEEEInt'lConf.
onDistributedComputingSystems(ICDCS).
IEEEPress,2009.
183190.
[doi:10.
1109/ICDCS.
2009.
45][6]Johnston-WattD.
Getsmart:Thecaseforintelligentapplicationmobilityinthecloud.
TheCloudComputingJournal,2010.
http://cloudcomputing.
sys-con.
com/node/1625129[7]MaLY,HuangG,LanL,LiuTC,WangM,FanG,MeiH.
Towardssoftwarearchitecturebasedapplicationdeployment.
In:Proc.
oftheNationalSoftwareApplicationConf.
2004(inChinesewithEnglishabstract).
[8]ZhangY,HuangG,ZhangW,LiuXZ,MeiH,YangSX.
Refactoringandroidjavacodeforon-demandcomputationoffloading.
In:Proc.
oftheObject-OrientedProgramming,Systems,Languages&Applications(OOPSLA).
ACMPress,2012.
233247.
[doi:10.
1145/2384616.
2384634][9]TilevichE,SmaragdakisY.
J-Orchestra:EnhancingJavaprogramswithdistributioncapabilities.
ACMTrans.
onSoftwareEngineeringandMethodology(TOSEM),2009,19(1):140.
[doi:10.
1145/1555392.
1555394][10]CecchetE,MargueriteJ,ZwaenepoelW.
PerformanceandscalabilityofEJBapplications.
In:Proc.
oftheObject-OrientedProgramming,Systems,Languages&Applications(OOPSLA).
ACMPress,2002.
246261.
[doi:10.
1145/582419.
582443][11]FowlerM,BeckK,BrantJ,OpdykeW,RobertsD.
Refactoring:ImprovingtheDesignofExistingCode.
Addison-Wesley,1999.
[12]MaleticJI,MarcusA.
Supportingprogramcomprehensionusingsemanticandstructuralinformation.
In:Proc.
oftheInt'lConf.
onSoftwareEngineering(ICSE).
IEEEPress,2001.
103112.
[doi:10.
1109/ICSE.
2001.
919085][13]TilevichE,SmaragdakisY.
PortableandefficientdistributedthreadsforJava.
In:Proc.
oftheACM/IFIP/USENIXInt'lMiddlewareConf.
(Middleware).
LNCSPress,2004.
478492.
[doi:10.
1007/978-3-540-30229-2_25][14]Knapsackproblem.
http://en.
wikipedia.
org/wiki/Knapsack_problem[15]StoerM,WagnerF.
Asimplemin-cutalgorithm.
JournaloftheACM,1997,44(4):585591.
[doi:10.
1145/263867.
263872][16]JMX.
http://www.
oracle.
com/technetwork/java/javase/tech/javamanagement-140525.
html[17]RUBiS.
http://rubis.
ow2.
org/[18]EBay.
http://www.
ebay.
com/[19]JonAS.
http://jonas.
ow2.
org[20]InternetWareTestBed.
http://edu-icloud.
internetware.
org/[21]ChenW,WeiJ,HuangT.
W4H:Ananalyticalframeworkforsoftwaredeploymenttechnologies.
RuanJianXueBao/JournalofSoftware,2012,23(7):16691687(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/4105.
htm[doi:10.
3724/SP.
J.
1001.
2012.
04105][22]SicardS,DePalmaN,HagimontN.
J2EEserverscalabilitythroughEJBreplication.
In:Proc.
ofthe21stAnnualACMSymp.
onAppliedComputing(SAC).
NewYork:ACMPress,2006.
778785.
[doi:10.
1145/1141277.
1141455][23]GordonMS,JamshidiDA,MahlkeS,MaoZM,ChenX.
COMET:Codeoffloadbymigratingexecutiontransparently.
In:Proc.
ofthe10thUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI).
USENIXPress,2012.
93106.
[24]HuntGC,ScottML.
TheCoignautomaticdistributedpartitioningsystem.
In:Proc.
oftheUSENIXSymp.
onOperatingSystemsDesignandImplementation(OSDI).
ACMPress,1999.
187200.
[25]PhilippsenM,ZengerM.
JavaParty:TransparentremoteobjectsinJava.
Concurrency:PracticeandExperience,1997,9(11):12251242.
[doi:10.
1002/(SICI)1096-9128(199711)9:113.
0.
CO;2-F]附中文参考文献:[1]杨芙清,梅宏,吕建,金芝.
浅论软件技术发展.
电子学报,2002,12(12A):19011906.
[3]杨芙清,吕建,梅宏.
网构软件技术体系:一种以体系结构为中心的途径.
中国科学(E辑:信息科学),2008,38(6):818828.
[doi:10.
1007/s11432-008-0051-z][4]梅宏,黄罡,兰灵,李军国.
基于体系结构的网构软件自适应方法.
中国科学(E辑:信息科学),2008,38(6):901920.
[doi:10.
1007/s11432-008-0052-y][7]马丽雅,黄罡,兰灵,刘天成,汪萌,范刚,梅宏.
基于软件体系结构的应用部署方法初探.
见:全国软件与应用学术会议.
北京,2004.
[21]陈伟,魏峻,黄涛.
W4H:一个面向软件部署的技术分析框架.
软件学报,2012,23(7):16691687.
http://www.
jos.
org.
cn/1000-9825/4105.
htm[doi:10.
3724/SP.
J.
1001.
2012.
04105]1730JournalofSoftware软件学报Vol.
24,No.
8,August2013张颖(1983-),男,四川乐山人,博士,讲师,CCF会员,主要研究领域为分布式系统,软件中间件,软件工程.
E-mail:zhang.
ying@pku.
edu.
cn梅宏(1963-),男,博士,教授,博士生导师,中国科学院院士,CCF高级会员,主要研究领域为软件工程,软件中间件,软件体系结构.
E-mail:meih@pku.
edu.
cn黄罡(1975-),男,博士,教授,博士生导师,CCF会员,主要研究领域为分布式系统,软件中间件,软件工程.
E-mail:hg@pku.
edu.
cn李影(1975-),女,博士,教授,博士生导师,CCF高级会员,主要研究领域为分布式系统,软件中间件,软件工程.
E-mail:li.
ying@pku.
edu.
cn刘儇哲(1980-),男,博士,副教授,主要研究领域为软件工程,服务计算.
E-mail:liuxzh@sei.
pku.
edu.
cn杨顺祥(1975-),男,博士生,主要研究领域为软件工程,软件测试技术.
E-mail:yangsx07@sei.
pku.
edu.
cn