Some notes on Web Services performance

I've been called into doing some software mercenary work for another product group here. This product provides a web services gateway using Apache Axis and after successive iterations of tests it was found that the server-side SOAP stack was the chief bottleneck. The team had moved from Axis 1.0 to 1.1 during the performance test cycle and had observed some modest gains, but not nearly enough. I found out that they were using the rpc/encoded style SOAP encoding. Now this is probably the most developer-friendly of the 3 encoding styles -- rpc/encoded, rpc/literal and document/literal -- but not the most efficient. It brings to mind a couple excellent articles, one by Frank Cohen (Discover SOAP encoding's impact on Web Service performance) and another by Dennis M. Sosnoski (Cleaning up SOAP Web Services::Test Results) on the topic. The rationale is really simple.

In the rpc/encoded model, you call a remote object and pass requisite parameters. It is the SOAP stack's responsibility to serialize your request parameters into XML format and to de-serialize them into objects from the response XML. One can imagine that for complex objects and large payloads, this can have an impact on performance.

The rpc/literal is a slight variation on the above. You can send raw XML data as a request parameter. The SOAP stack serializes this single XML data parameter, binding the request to the remote object. Unlike the rpc/encoded model, the overhead here is just of serializing and de-serializing a single parameter.

Now in the document/literal model, your request is actually an XML document. So is the response. The onus is on you to write the logic to extract the SOAP envelope's body element and parse the XML response.

So why do we choose development-time ease at the price of runtime penalties on scalability and performance? My opinion is this may be due to lack of awareness, not lack of diligence. That tools like Apache Axis (which is by no means the only one to do this) default to rpc/encoded as the out-of-the-box encoding style only exacerbates the problem. I think Microsoft may have got it right in this case. The .NET implementations default to document/literal.

I realize that Axis has a 1.2 beta out but do not know if any significant performance gains can be achieved with that. Going to production with a 'beta' version of an important cog in the wheel scares most decision makers.

Email this | Bookmark this