Axis performance enhancement

[Dennis Sosnoski]

I've been doing some investigations into Axis performance issues. I've mainly been looking at RPC-encoded, since that seems to be the bulk of the web services world (at least, outside of .NET). One thing I've noticed is the amount of redundant information in the encoding of multiRefs. In normal operation Axis adds the encoding information and namespace definitions to each child element of <soapenv:Body>. By moving these (the encoding, the encoding namespace, and the main element namespace definition) up to the <soapenv:Body> element itself I was able to reduce the total size of the messages (originally 10KB to 320KB) by 25-30% and cut processing time by 10-25% (with more improvement on longer messages, and processing time measured running client and server on the same system over local HTTP).

Turning off type information also helped reduce the message size and improve performance considerably. The combination of turning off type information and moving the encoding and namespaces to the <soapenv:Body> element together cut the message size by more than 50% and processing time by 20-50%.

Turning off server-side type information in the 1.0 release version was easy, changing the setting in the server-config.wsdd file. On the client side I couldn't find any easy way to do this through code generated from WSDL, so I modified the client.Call class to just always set this property in the MessageContext. When I tried using the 11-24 daily build I couldn't get this to work anymore - I ended up with exceptions from both ends when the other side turned off type information. I also had problems with WSDL generation in the daily build, so I just went back to using the 1.0 release for my tests. Considering the benefits you might want to consider making untyped the default for the next release, while giving users an easy way to turn it back on for both client and server side code.

I implemented the move of encoding and encoding namespace to the <soapenv:Body> element by modifying the SOAPBody outputImpl() method so that it "reverse inherits" the encoding from the first bodyElement, if present, then calls context.registerPrefixForURI() to define the namespace for the encoding. This seems fairly safe, though there's probably a cleaner way - I'll supply a diff if there's interest. The main namespace for the elements I just set directly, since I didn't dig around enough to see how to derive it.

Aside from that, Axis is considerably slower in working with the XML (both input and output) than DOM or dom4j, for instance. I'm still trying to learn the details and logic of the internal handling, but I'm beginning to see how JAX-RPC compatibility really restricts the type of approaches that can be used for performance enhancements. I *have* got a few areas I want to look into in more detail, though, and should get a chance to do that in a week or so. I'll try to submit actual code rather than just comments and suggestions when I do!

Hope this is of interest,

- Dennis