axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: Axis performance enhancement
Date Mon, 25 Nov 2002 12:35:21 GMT
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 <dms@sosnoski.com> 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

Mime
View raw message