张家超,郑扬飞
(华北计算技术研究所,北京100083)
Web服务是互联网技术环境下一种日益广泛应用的分布式计算技术模式。它面向开放的互联网协议,采用通用、现有的技术和基础设施,具备语言和平台无关性、松散耦合性、以及不同系统间无限交互的潜能。
Web服务最大魅力在于其开放性而得以不断发展,从而能够包容电子商务、企业应用集成 (enterprise application integration,EAI)、传统的中间件以及Web技术[1]。这也使得Web服务的性能问题越来越受到关注。由于Web服务中传输消息的SOAP(simple object access protocol)[2]报文基于可扩展标记语言 (extensible markup language,XML)[3],而XML的文本特点使它相较二进制报文长度更长,且花费更多的解析时间。这些技术上的缺陷使Web服务的性能与传统分布式计算技术 (如common object request broker architecture, CORBA[4];Java remote method invocation, Java RMI[5])相比存在一定差距,文献[6]对比了 Web 服务和CORBA的性能差异。Web服务的性能问题正决定着它的进一步发展。
学术界和工业界就如何优化Web服务性能,已积累了一些不同层面的成果。文献[7]提出了一种二进制优化打包机制 (XML-binary optimized packaging,XOP),文献[8]提出的消息传输优化机制 (message transmission optimization mechanism,MTOM)正建立在前者的基础上,它们提出针对二进制数据的打包传输进行优化的思路。此外,还有其他层面的优化思路,如通过压缩SOAP消息以优化Web服务性能[9-10]。
一个典型的Web服务模型,通常涉及到三个核心协议:服务提供者用以描述和发布服务的Web服务描述语言(web service description language,WSDL)[11],服务使用者用来查找服务的通用描述发现与集成协议 (universal description discovery and integration,UDDI)[12],服务提供者与使用者之间传递服务的简单对象访问协议SOAP。
图1展示了一次完整的Web服务调用过程:从客户端(Client)发出的请求在XML序列化后经由网络抵达Web服务端 (Server),并由服务端进行SOAP报文的解析、验证过程,调用Server端提供的服务,之后向客户端返回一个响应报文,同理,客户端解析和验证收到的响应报文也需花费时间和资源。
图1 Web服务调用模型
未经优化的正常报文,例如由Server端向Client端发送一张JPG格式的图片,由于XML序列化基于文本,所以该JPG图片二进制码将转成 Base64[13]编码并嵌入返回的SOAP报文中。鉴于Base64编码的编码规则,会导致其在体积上有约33%的膨胀[14],相应的传输和存储过程都将消耗更多资源。
MTOM基于XOP,XOP允许将二进制数据直接作为附件传送,而无须对二进制数据进行XML序列化,从而在报文大小上有明显的缩减 (第3节的实验数据将显示约有30%的缩减)。图2说明了XOP优化的原理:左侧为嵌入Base64编码的SOAP报文,XOP采用<xop:Include>的标签代替属于Base64编码出现的位置,并引用一个cid;该cid指向由它标识的二进制附件,添加到重新打包后的底部;同时在新报文的顶部添加Content-type、start、boundary等说明性信息。
虽然XOP引入了额外的处理机制,但XML序列化的简化、报文体积的缩减更能影响性能的提升。需说明,图2中的Base64编码仅为示意,截取自下文实验中taishan(泰山)对应报文的编码头部,实际用例中Base64编码体积会很大。
图2 XOP优化原理
通过第1节对MTOM性能优化的分析,不妨提出一个假设:对于二进制文件传输,MTOM方式会有较明显的性能优化,现在的主要目标是通过构建实验方案,验证不同环境下MTOM能得到多大程度的优化。
接下来问题可以分解为:
(1)开发一组功能相同的Web服务原型,分别提供未经优化和经MTOM优化的响应。
(2)测试该组Web服务在相同环境下 (如相同传输样本、宽带宽或窄带宽环境)性能数据的差异,验证性能优化的假设。
(3)分析实验得到的数据,得出结论。
实验要求开发部署一组Web服务原型,本文方案:开发功能相同的两个Web服务,WuyueImageService和Wuyue-ImageMTOMService。其功能均为根据请求返回存储在服务器端的五岳的图片:如请求songshan,则返回服务器上指定的嵩山图片;请求huashan,则返回华山的图片。
虽然功能相同,但WuyueImageService返回的是未经优化的正常响应,即在响应报文中内嵌图片对应的Base64编码;而WuyueImageMTOMService返回的是MTOM优化的报文,即将图片对应的二进制码作为附件传送。
在本地局域网 (local area network,LAN)环境下,部署如图3所示。
图3 实验部署
本例的Web服务由JAX-WS开发,通过Endpoint端点发布程序直接将服务分别发布在服务器端(192.168.101.63)的9876和9999两个端口上。在客户端(192.168.101.90)部署SoapUI作为测试工具,分别向服务器端两个Web服务发送底层的SOAP请求。
SoapUI采用Simple测试策略,Seconds Limit模式,设置请求脚本间零延时,默认单线程请求,每种取样类型均进行600秒、1200秒、1800秒三组测试。
(1)带宽:本实验在100Mbit LAN环境下进行,并通过设置网卡模式来模拟10Mbit窄带宽环境。
(2)压力:以单线程实验数据为准,实际开展实验时进行了大量多线程测试 (5/10Threads),多线程下最终的优化效果并无差异。
(3)测试指标:以平均响应时间、限定时间内处理请求数/单位时间处理请求数、吞吐量为主。
(4)样本:分为三种取样类型:只请求songshan、只请求chinamap、依次请求五岳全部。样本图片均为JPG格式,大小如表1所示。
表1 样本图片大小
(5)实验环境:JDK1.7.0_03。服务器端Intel Core2 Q8400(2.66GHz,2.66GHz)、3.21GB RAM、Windows XP SP3(32位);客户端 Intel(R)Xeon E5504(2.00GHz,2.00GHz)、64.0GB RAM,Windows Server2008R2 Enterprise(64位)。涉及工具有SoapUI4.5.0-Beat1、TCPMon1.0。
在性能数据的统计与分析之前,首先应验证服务原型的正确性。利用以转发机制为原理的工具TcpMon来追踪传输层的报文。以客户端请求taishan(泰山)为例,截获WuyueImageService和 WuyueImageMTOMService两种服务的请求和响应报文如图4所示。
图4 TcpMon捕获的报文
图4 (a)显示内嵌taishan(泰山)Base64编码的响应报文,而图4(b)显示的响应报文则将二进制数据作为附件跟在Content-Id为“12687b59-b2e3-4527……”的标识之后,并指明其内容类型 (content-type)为application/octetstream,内容传输编码 (content-transfer-encoding)为binary。观测客户端SoapUI收到的报文,见图5,收到一个大小为51103Bytes的附件 (跟表1中taishan的图片大小完全一致),直接打开附件即显示正确的泰山图片。
图5 SoapUI收到含有二进制附件的报文
由此可见,Web服务原型达到了预期的效果,两种服务都能提供正确的响应报文,而且报文大小有明显的缩减(约30%),统计截获的请求/响应报文大小如表2所示,其中缩减比率=(Base64-MTOM)/Base64:
表2 Base64与MTOM请求/响应报文大小对比统计
分别在宽带宽、窄带宽环境下,依次进行三类测试:请求songshan、chinamp、全部五岳;其中,chinamap代表大数据二进制文件进行性能优化测试;统计五岳时,一次测试包括依次五岳的请求/响应过程,统计数据取其平均值,以说明依次请求大小各异的五岳样本时的优化效果。
选取的主要性能指标表示为:avg(平均响应时间,毫秒),cnt(处理请求数,个数),tps(每秒处理请求数),bytes(限定时间内的总吞吐量)。
3.2.1 100Mbit LAN环境
如表3(a-c)统计了在100Mbit LAN环境下的各组实验数据,可以明显看到MTOM方式得到的各项数据均有一定程度的优化。
3.2.2 10Mbit环境
10Mbit窄带宽环境下,实验数据如表4(a-c)所示。
表3 100Mbit LAN环境实验数据
表4 10Mbit窄带宽环境实验数据
(c) 10Mbit 窄带宽请求五岳的平均性能数据性能限时avg cnt/tps bytes Base64 MTOM Base64 MTOM 600s 3770.76 3047.67 159/0.26 197/0.32 587,517,720 546,614,Base64 MTOM 324 1200s 3754.02 3044.68 320/0.26 394/0.32 1,182,425,600 1,093,228,648 1800s 3749.46 3065.01 480/0.26 587/0.32 1,773,638,400 1,628,744,204
分析实验数据可以发现,报文体积的缩小,直接反映在平均响应时间的减短,在限定时间内,仅需更少的吞吐量 (92% ~99%,计算自表3、表4)就可以处理更多的请求数。以限定时间内处理请求数cnt作为性能优化的标准,绘制性能优化结果如图6所示。
图6 100Mbit LAN环境性能优化
针对3种取样类型,各自进行的三组限时测试均呈现明显的线性,说明测得的数据十分规律和稳定;即便对较大的二进制文件chinamap,MTOM也同样呈现出近30%的性能优化效果。而请求五岳图片,因为实际是将5个请求/响应的过程作为一次cnt统计,多次的报文收发过程和平均值计算对数据有一定影响,但平均值依然表现出约22%的优化效果。
10Mbit环境性能优化效果如图7所示,统计表现出和宽带宽环境相同的优化效果,在处理请求的能力上表现出近30%的提升,同样这是在占用更少吞吐量的情况下完成。
图7 10Mbit窄带宽环境性能优化
通过对实验结果的分析,可以得出结论:
(1)优化后的报文在大小上比传统报文缩减了约30%。
(2)伴随平均响应时间减短,反映在处理请求数cnt(或单位时间处理请求数tps)上,有近30%的性能提升。
(3)100Mbit LAN环境和10Mbit窄带宽呈现出相同的优化效果。
(4)传输较大的二进制文件,同样有理想的优化效果。
因此,MTOM在适合二进制文件传输的场景有着很大的应用空间,尤其是要求高性能、大数据量传输的Web服务中,如多媒体流处理[15-16]、GIS服务、高性能科学计算等场景,采用MTOM可以有效的提升Web服务的性能。
本文分析Web服务模型以及性能提升方法,针对二进制数据打包优化,提出实验方案,设计并实现一组Web服务原型,用数据证明了MTOM可得到近30%的性能优化效果。但是,总结实验遇到的问题,还存在许多进一步开展工作的空间。
在Internet环境下,网络拥塞的变化会导致Web服务的性能起伏,传输时间对Web服务性能的影响程度将大大加重,有必要验证Internet不同网络环境下Web服务的性能优化效果;从应用角度,将MTOM应用于现有的业务系统,与系统功能融合、进行性能优化;此外,XML编码技术直接影响Web服务序列化/反序列化性能,是值得深入研究Web服务性能优化的技术,可在下一步研究中,作为性能优化的深入方向。
[1]Michael P Papazoglou.Web Services:Principles and technology[M].GONG Ling,transl.Beijing:Machine Press,2010:28-28(in Chinese).[Michael P.Papazoglou.Web服务:原理和技术 [M].龚玲,等译.北京:机械工业出版,2010:28-28.]
[2]Simple object access protocol(SOAP)version 1.2 [S].W3C Group,http://www.w3.org/TR/soap/,2007.
[3]Extensible markup language(XML)1.1 [S].2nd ed.W3CGroup,http://www.w3.org/TR/2006/REL-xml11-20060816/,2006.
[4]The common object request broker:Architecture and specification rev 3.2 [S].Object Manag-ement Group,http://www.omg.org/spec/CORBA/3.2,2011.
[5]SUN Microsystems.JavaTMRMI release notes[EB/OL].[2012-05-12].http://docs.oracle.com/javase/1.5.0/docs/-guide/rmi/relnotes.html.
[6]LIU Zhongfeng.Comparsion and implementation of CORBA services and web services[D].Wuhan:Wuhan University of Technology,2011:12-14(in Chinese).[刘中锋.CORBA服务与Web服务的比较[D].武汉:武汉理工大学,2011:12-14.]
[7]XML-binary optimized packaging [S].W3C,http://www.w3.org/TR/xop10/,2005.
[8]SOAP message transmission optimization mechanism [S].W3C,http://www.w3.org/TR/soap12-mtom/,2005.
[9]Mike Nikitas.Improve XML web services’performance by compressing SOAP[EO/BL].[2003-01-01].http://www.drdobbs.com/windows/improve-xml-web-services-performanceby/219401262.
[10]Júlio Cezar Estrella,Marcos JoséSantana,Regina H CSantana,et al.Real-time compression of SOAP messages in a SOA environment[C]//Lisbou,Portugal:SIGDOC’08 Proceedings of the 26th ACM international conference,2008:163-168.
[11]Web services description language(WSDL)Version 2.0 Part1:Core language [S].W3C Group,http://www.w3.org/TR/wsdl,2007.
[12]UDDI Version 3.0.2 UDDI spec technical committee draft[S].UDDI Org,http://uddi.org/pu-bs/uddi-v3.0.2-20041019.html,last modified,2006.
[13]The Base16,Base32,and base64 data encoding [S].Network Working Group,http://tools.ietf.org/html/rfc4648,2006.
[14]Wikipedia.Message transmission optimization mechanism [EB/OL].[2012-01-23].http://en.wikipedia.org/wiki/MTOM./.
[15]Gibson Lam,David Rossiter.A web service framework supporting multimedia streaming [J].Services Computing,IEEE Transactions on,2012(4):99-113.
[16]Nils Gruschka,Luigi Lo Iacono.Server-side streaming processing of secured MTOM Attach-ments[C]//Ayia Napa,Cyprus:Eighth IEEE European Conference on Web Services,2010:11-18.