Thanks for taking the time for this very important issue. Looking forward to patches/test-cases from you. Please add them to bugzilla directly and one of us will look into it.
Thanks, dims --- Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > 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 > ===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
