4 Replies Latest reply on Aug 16, 2004 3:39 PM by Joey Bernard

    Performance with large SOAP messages

    Joey Bernard Newbie

      I have an app that uses the bean serializer to go through and serialize data being gathered from a database. For average sized queries, it works fine. But for larger queries, the response time goes up into the several minutes range. I'm wondering if anyone else has any ideas on what I can do to improve the performance. By looking in the log files, I know that 2/3 to 3/4 of the time is being spent creating the SOAP message, so that is where I need to improve the performance. Is the only option to skip over using the Xerces parser and write my own?

        • 1. Re: Performance with large SOAP messages
          Joey Bernard Newbie

          Just as a followup, I've already tried installing the latest Xerces parser to see if that might help. No luck.

          • 2. Re: Performance with large SOAP messages
            elizabeth roush Newbie

            Can you share your SOAP message sizes: average size vs large size? Also what platform you are running JBOSS on? I am interested in the performance impact of JBOSS.NET on large soap messages.

            I think you may be correct in that the parsing is not scaling well on the larger messages.

            I'm assuming you are using the RPC style message format which is the default when you follow the JBOSS example for exposing an EJB as a webservice. In this case, org.apache.axis.providers.java.RPCProvider is what is used to deserialize the SOAP request message to the ejb and serialize the ejb to the SOAP response message.

            You can deploy a simple webservice in JBOSS and handle the soap message yourself. http://ws.apache.org/axis/java/user-guide.html "Message Services" section talks about how to do this. (http://www.csd.abdn.ac.uk/~bscharla/teaching/mtp_software/jboss/jboss-net-HelloWorld.shtml talks about how to tweak it to work with JBOSS.NET.)

            In this instance the service handler is org.apache.axis.providers.java.MsgProvider. Rather than deserializing the soap request to an ejb, it deserializes the soap request based on the method signature you implemented. For example implementing public void method(SOAPEnvelope req, SOAPEnvelope resp);
            MsgProvider will deserialize the SOAP request to, and serialize the response from: org.apache.axis.message.SOAPEnvelope. This way you can deal with the xml parsing yourself (most of it anyway, there is minimal parsing done by MsgProvider to deserialize into SoapEnvelope). This method also allows you access to the SOAPHeaders.

            There are third party tools available such as xmlbooster (www.xmlbooster.com) which generate xml parsers which claim to be faster than geneneric xml parsers like Xerces. This is because it generates an xml parser specific to the xml message you want to process.

            Of course if the xml is fairly simple and rarely changes you can just extract out what you need in the SOAP request and build the response message yourself. There are several apis to do so, sun SAAJ is the one I use.

            E Roush

            • 3. Re: Performance with large SOAP messages
              elizabeth roush Newbie

              Look at "Discover SOAP encoding's impact on Web service performance"

              (http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/ )

              which not only explains the performance impact of different encoding styles: rpc/encoded, rpc/literal, document/literal but also offers free test suite to test on your system. Their results? rpc/encoded takes a major performance hit with large soap messages.

              • 4. Re: Performance with large SOAP messages
                Joey Bernard Newbie

                I've been busy for a while, so I haven't had time to come back to this till now. Thanks for the pointers. I'll check them out. As for the platform, this running under Java1.4.2 on a Solaris box. I think it's an 880, but I'm not sure (not in charge of the infrastructure stuff). When I get in tomorrow I'll post some performance measures of what is normal, big and how long the web service spends on each.