Web services tuning tips

Web services performance is affected primarily by these characteristics of the XML documents that are sent to Web services:

• Size refers to the length of data elements in the XML document.
• Complexity refers to number of elements that the XML document contains.
• Level of nesting refers to objects or collections of objects that are defined within other objects in the XML document, as in this example:

  <primaryObject>
    <groupObject>
      <singleObject/>
      <singleObject/>
    </groupObject>
  </primaryObject>
  

In addition, a Web services engine contains three major pressure points that define the performance of Web services:

• Parsing (Input): When a request is received, the Web services engine parses the input. There are two major performance components in parsing:
  • scanner
  • symbol or name identification

• XML-to-object deserialization (Input): As the document is parsed the XML input is deserialized and converted into business objects that are presented as business object parameters to the Web services. The Web services provider, either a JavaBean provider or an enterprise bean provider, is not aware of its participation in a Web service.
• Object-to-XML serialization (Output): After the request is processed, reply is serialized into an XML document. Large documents or complex objects can affect output serialization.

Web Services Best Practices

• Use WebSphere Application Server Web services instead of SOAP
  The WebSphere Application Server Web services implementation performs better than the SOAP implementation based on Apache SOAP. WebSphere Application Server includes support for the Apache SOAP implementation so that you can run existing Web services applications.

• Avoid large or complex XML documents
  The performance of Web services is directly related to the size and complexity of the XML document that is transferred. As input documents increase in size or number of elements, they require more processing for both parsing and deserialization. As output documents increase in size or number of elements, they require more processing for serialization.

• Avoid small, frequent requests
  By definition, every Web services request is a remote request. These requests usually involve the Web container or Java Messaging Service (JMS) in addition to the XML overhead of parsing and deserialization. To send or retrieve a 50K object that has 10 properties that are each 5K long, you can retrieve the object in several ways, such as:

  • As one 50K request
  • As 10 5K requests
  • As 50 1K requests

  Because of the overhead associated with the Web container or JMS, it is more efficient to transfer a single 50K request than several smaller requests.

• Limit the level of nesting in XML documents
  Increasing the level of object nesting results in an increase in the number of objects that are deserialized and created when a request is processed. An object that is composed only of primitive types or strings is processed more efficiently than a similar size object composed of deeply nested Java objects.

• Use WebSphere Application Server custom serializers
  The WebSphere Application Server Web services engine provides serialization and deserialization helpers that improve runtime performance for business objects. These custom serializer and deserializer helpers specifically describe an object's properties. As a result, the Web services runtime consumes fewer resources to obtain information about the object.

• When possible, use literal encoding instead of SOAP encoding
  Use literal encoding instead of SOAP encoding. Literal and SOAP encoding are alternate forms for encoding Web services requests and responses. SOAP encoding is the older and now less commonly used form of Web services encoding. Each element in the SOAP body includes the XML Schema definition type of the data element. SOAP encoding was needed to make the message self-defining. SOAP encoding with the embedded data types increases the amount of data transferred in the Web services request. We previously established the performance impact of XML message length. Figure 6 shows a comparison of data lengths for SOAP encoding versus document/literal for a typical workload.

• Use descriptive but short property names
  Web services is an XML text-based exchange protocol, and the names of variables and properties are included in the XML for the SOAP body portion of the message. Longer property names increase the size of the XML document.

• When possible, use JavaBeans instead of session beans
  J2EE Web services includes two server or provider types: JavaBean and session bean. Session beans provide well-defined interfaces that characterize a distributed service endpoint. However, there is extra overhead associated with session beans.

  Consider using a JavaBean instead of a session bean as the Web services provider. JavaBeans are not suitable in all cases; sometimes enterprise bean services are required for security and transactions. These factors are more important than the performance benefit of a JavaBean provider. However, if neither transactions nor security are needed for your Web service, a JavaBean provider might provide improved performance for your application.

• Use 'Pass by Reference'
  If you choose to use a session bean provider for your Web service, it is recommended that you use the WebSphere Application Server enterprise bean/IIOP Pass by Reference optimization, No Local Copies.