(ZOS) Tune for SOAP

Learn how to tune the soap messages that we use with the web services.

SOAP is a lightweight protocol which provides a mechanism to use XML for exchanging structured and typed information between peers in a decentralized, distributed environment.

Tasks

• Specify noLocalCopies in servant.jvm.options (-Dcom.ibm.CORBA.iiop.noLocalCopies=1). This will enable passing of parameters by reference instead of by value. This only applies if we are exposing an enterprise bean as a web service. To learn more, see the object request broker service settings information.

• Make certain that all traces are disabled unless we are actively debugging a problem.

• When defining transaction policies for the application, specify TX_NOT_SUPPORTED and select local transactions. Local transactions perform better than global transactions because WebSphere is not required to coordinate commit scope over multiple resource managers.
• Avoid passing empty attributes or empty elements in SOAP messages. Do not include extraneous and unneeded data in SOAP messages. If we can use document/literal style web services invocation to batch requests into a single SOAP message, this is preferable to sending multiple individual SOAP messages. SOAP applications will perform better with smaller SOAP messages containing fewer XML elements and especially fewer XML attributes. The contents of SOAP messages must be serialized and parsed. These are expensive operations and should be minimized. In other words, it is preferable to send 1, 10KB message than 10, 1KB messages. However, very large messages (for example, over 200KB) might impact system resources like memory.

• We might need to increase the default Java heap size. SOAP and XML (DOM) are storage-intensive and small heap sizes can result in excessive Java garbage collection. We found a heapsize of 256M (the default) was optimal for most test cases in the laboratory. We can monitor garbage collection using the verbose:gc Java directive.
• Insure TCP/IP send/receive buffers are large enough to hold the bulk of the xml messages that will be sent.
• Consider using a Document Model rather than the RPC model. It provides complete control over the format of the XML but requires additional programming effort.

• When using RPC-style messages, try to send strings if possible.

• For JAX-RPC web services, consider writing our own serializers and deserializers, avoiding reflection.

Object Request Broker service settings