Learn how to tune the soap messages that you use with your
web services.
About this task
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.
Procedure
- 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 you 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 you are
actively debugging a problem.
- When defining transaction policies for your 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 you 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.
- You 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. You 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 Java API for XML-based RPC (JAX-RPC)
web services, consider writing your own serializers and deserializers,
avoiding reflection.