Santiago Pericas-Geertsen's Blog

MTOM Performance in JAX-WS

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:

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.

Comments

• There don't appear to be any hardware platform or network specs (i.e. 1Gb, 100base-t, intra-platform, etc.) in the article. Are these specs available?

  Posted by: gsl1 on May 23, 2006 at 10:35 AM

• The test was executed on a 2 GB 2-way v20z (Opteron) in network loopback mode. Service running on Glassfish with a single client thread. Java 5.0 and Solaris 10. Thanks.

  Posted by: spericas on May 23, 2006 at 03:43 PM

• Based on my calculations for the 192k payload data point, you demonstrate 192k/11ms = approximately a 17.5MB/s transfer rate. I assume that k implies k bytes and not bits. Given that the v20z comes standard with at least one SCSI Ultra320 disk and you used a network loopback, it _seems_ that MTOM is still quite inefficient in transferring a binary payload. Have you analyzed where the bulk of the transfer time is being spent? and also the distribution of the transfer time, i.e. message header en/decode, vs. binary transfer, etc.?

  Posted by: gsl1 on May 26, 2006 at 12:18 PM

This work is licensed under a Creative Commons License.