IBM WebSphere Application Server Performance Cookbook

Web Services

This chapter mostly only applies if the application uses the IBM web services engine. If a third party engine (or HTTP client) is used, separate tuning must be reviewed for that framework.

General web service tuning tips

  1. Review the Web services performance best practices
  2. Review the custom properties of the HTTP transport chain for web services
  3. Reduce the time to create the JAXBContext with -Dcom.ibm.ws.websvcs.getJAXBContext.cacheClassList.persist=true and other application best practices
  4. If applicable and if using JAX-WS and WAS >= 8.5.5.2, set -Dcom.ibm.websphere.webservices.jaxwsOptimizeLevelOne=true
  5. If you use transport level security for XML encryption or digital signatures, consider using the unrestricted JCE policy files
  6. If using JAX-RPC, consider testing the relative benefit of response compression using -Dcom.ibm.websphere.webservices.http.responseContentEncoding
  7. If sending web services requests from an MDB, use -Dcom.ibm.ws.websvcs.transport.jms.cacheReplyQCF=true
  8. If using JAX-WS on WAS >= 8.5.5.2, consider setting -DcacheTransformerFactory=true
  9. If using a JAX-WS client with WAS security enabled and WS-Reliable Messaging is not needed, consider setting -Dcom.ibm.websvcs.client.serializeSecurityContext=false

Outbound Connection Cache

If using the web service client, tune -Dcom.ibm.websphere.webservices.http.maxConnection=X based on the thread pool size and backend capacity.

For performance reasons, ensure that the com.ibm.websphere.webservices.http.maxConnection custom property is at least half the size of the maximum number of threads in the web container thread pool. The default size for the web container thread pool is 50. As a result, the default size of the com.ibm.websphere.webservices.http.maxConnection property is set to 25 and 50 for JAX-RPC and JAX-WS, respectively. You can adjust the setting for com.ibm.websphere.webservice.http.maxConnection upwards from this initial value, as required, to better utilize the threads.

The outbound connection cache does not have PMI monitoring but does have a lightweight diagnostic trace:

  • JAX-WS: *=info:com.ibm.ws.websvcs.transport.channel.Monitor=all
  • JAX-RPC: *=info:com.ibm.ws.webservices.engine.transport.channel.Monitor=all

WSPerf Tool

Investigate JAX-WS or JAX-RPC performance using diagnostic trace.

Inbound Web Services Processing

Monitor PMI statistics on inbound web services processing

Preferring Local Execution

If the web services client is running in the same JVM as the web service target, consider using the optimized local communication path:

To improve performance, there is an optimized communication path between a web services client application and a web container that are located in the same application server process. Requests from the web services client that are normally sent to the web container using a network connection are delivered directly to the web container using an optimized local path. The local path is available because the web services client application and the web container are running in the same process.

The optimized local communication path is disabled by default. You can enable the local communication path with the enableInProcessConnections custom property. Before configuring this custom property, make sure that you are not using wildcards for host names in your web container end points. Set this property to true in the web container to enable the optimized local communication path. When disabled, the web services client and the web container communicate using network transports.

Web Services Response Caching

Service Servlet Caching

Consider using Dynacache to cache web service responses.

JAX-RPC Client Caching

If using JAX-RPC, enabling the web services client cache is an option to improve the performance by using the dynamic cache service to save responses from remote web services for a specified amount of time. You enable the web services caching by enabling the dynamic cache service and servlet caching. After a response is returned from a remote web service, the response is saved in the client cache on the application server. Any identical requests that are made to the same remote web service are then responded to from the cache for a specified period of time. The web services client cache relies primarily on time-based invalidations because the target web service can be outside of your enterprise network and unaware of your client caching. Therefore, you can specify the amount of time in the cache and the rules to build cache entry IDs in the cache in your client application.