基于MTOM的Web服务性能优化研究

张家超，郑扬飞

(华北计算技术研究所，北京100083)

0 引言

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］。

1 概念和原理分析

一个典型的Web服务模型，通常涉及到三个核心协议:服务提供者用以描述和发布服务的Web服务描述语言(web service description language，WSDL)［11］，服务使用者用来查找服务的通用描述发现与集成协议 (universal description discovery and integration，UDDI)［12］，服务提供者与使用者之间传递服务的简单对象访问协议SOAP。

1.1 Web服务调用模型

图1展示了一次完整的Web服务调用过程:从客户端(Client)发出的请求在XML序列化后经由网络抵达Web服务端 (Server)，并由服务端进行SOAP报文的解析、验证过程，调用Server端提供的服务，之后向客户端返回一个响应报文，同理，客户端解析和验证收到的响应报文也需花费时间和资源。

图1 Web服务调用模型

1.2 MTOM性能优化分析

未经优化的正常报文，例如由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优化原理

2 对比实验设计

通过第1节对MTOM性能优化的分析，不妨提出一个假设:对于二进制文件传输，MTOM方式会有较明显的性能优化，现在的主要目标是通过构建实验方案，验证不同环境下MTOM能得到多大程度的优化。

接下来问题可以分解为:

(1)开发一组功能相同的Web服务原型，分别提供未经优化和经MTOM优化的响应。

(2)测试该组Web服务在相同环境下 (如相同传输样本、宽带宽或窄带宽环境)性能数据的差异，验证性能优化的假设。

(3)分析实验得到的数据，得出结论。

2.1 实验方案

实验要求开发部署一组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秒三组测试。

2.2 实验参数

(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。

3 实验结果

3.1 报文

在性能数据的统计与分析之前，首先应验证服务原型的正确性。利用以转发机制为原理的工具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请求/响应报文大小对比统计

3.2 性能数据

分别在宽带宽、窄带宽环境下，依次进行三类测试:请求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

4 实验分析

分析实验数据可以发现，报文体积的缩小，直接反映在平均响应时间的减短，在限定时间内，仅需更少的吞吐量 (92% ～99%，计算自表3、表4)就可以处理更多的请求数。以限定时间内处理请求数cnt作为性能优化的标准，绘制性能优化结果如图6所示。

图6 100Mbit LAN环境性能优化

针对3种取样类型，各自进行的三组限时测试均呈现明显的线性，说明测得的数据十分规律和稳定;即便对较大的二进制文件chinamap，MTOM也同样呈现出近30%的性能优化效果。而请求五岳图片，因为实际是将5个请求/响应的过程作为一次cnt统计，多次的报文收发过程和平均值计算对数据有一定影响，但平均值依然表现出约22%的优化效果。

10Mbit环境性能优化效果如图7所示，统计表现出和宽带宽环境相同的优化效果，在处理请求的能力上表现出近30%的提升，同样这是在占用更少吞吐量的情况下完成。

图7 10Mbit窄带宽环境性能优化

5 实验结论

通过对实验结果的分析，可以得出结论:

(1)优化后的报文在大小上比传统报文缩减了约30%。

(2)伴随平均响应时间减短，反映在处理请求数cnt(或单位时间处理请求数tps)上，有近30%的性能提升。

(3)100Mbit LAN环境和10Mbit窄带宽呈现出相同的优化效果。

(4)传输较大的二进制文件，同样有理想的优化效果。

因此，MTOM在适合二进制文件传输的场景有着很大的应用空间，尤其是要求高性能、大数据量传输的Web服务中，如多媒体流处理［15-16］、GIS服务、高性能科学计算等场景，采用MTOM可以有效的提升Web服务的性能。

6 结束语

本文分析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.