Skip to main content

MTOM Performance in JAX-WS

Posted by spericas on April 28, 2006 at 9:10 AM PDT

Since XML is a textual format, binary blobs must be represented as characters when embedded in an XML document. A popular encoding that permits this embedding is known as base64 encoding, and it corresponds to the XML Schema data type xsd:base64Binary. In a Web services toolkit that supports a binding framework, as it is the case in JAX-WS, a value of this type must be encoded before transmission and decoded before binding. The encoding and decoding process is expensive and linear to the size of the binary object. Moreover, the number of characters in the base64 encoding can be as much as one third greater than the number of bytes in the original binary blob.

The SOAP Message Transmission Optimization Mechanism, paired with the XML-binary Optimized Packaging [XOP], was proposed to address the inefficiencies related to the transmission of binary data in SOAP documents. This solution proposes a method in which XML messages are dissected in order to transmit binary blobs as MIME attachments in a way that is transparent to the application. Since an attachment is not really part of the XML payload, binary data does not need to be base64 encoded, thus reducing its size and increasing its processing speed.

The consequence of using MTOM is that message payloads are MIME packages as opposed to plain XML documents. Now is the cure worse than the illness? That is, does the overhead of processing MIME packages offset the benefits of avoiding base64 encoding? As you may expect, the answer to this question depends on the size of the binary payload --and, naturally, on the quality of the MTOM implementation!

Without attempting to offer a general rule of thumb, I wrote a Japex configuration file to find the "MTOM threshold" in JAX-WS using Glassfish. Here is the resulting chart:


mtom-threshold.jpg

The Y axis shows latency and the X axis a data point for each of the test cases in the benchmark. Note that the size of the binary payload increases linearly up to 6K and then exponentially up to 192K, hence the shape of the latency curve. Based on this chart, it appears that the MTOM threshold for JAX-WS is about 4K to 5K.

More experimentation is needed to determine this threshold's variance based on the deployment configuration (server type, container, etc.), but a data point is better than no data point :) Hope you find this information useful the next time you deploy a JAX-WS endpoint running on Glassfish.

Related Topics >>