基于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.