Tuning Web Services

The following sections contain Oracle best practices for designing, developing, and deploying WebLogic Web Services applications and application resources:

Web Services Best Practices

Design and architectural decisions have a strong impact on runtime performance and scalability of Web Service applications. Here are few key recommendations to achieve best performance.

Design Web Service applications for course-grained service with moderate size payloads.
Choose correct service (RPC or Document) and encoding (Encoded or Literal) style.
Control serializer overheads and namespaces declarations to achieve better performance.
Use MTOM/XOP or Fast Infoset to optimizing the format of a SOAP message.
Carefully design SOAP attachments and security implementations to minimize negative performance.
Consider using an asynchronous messaging model for applications with:

Slow and unreliable transport.
Complex and long-running process.
For transactional Service Oriented Architectures (SOA) consider using the Last Logging Resource transaction optimization (LLR) to improve performance. See Tuning Logging Last Resource.

Use replication and caching of data and schema definitions to improve performance by minimizing network overhead.
Use XML compression where the XML compression overhead is less than network latency.
Applications that are heavy users of XML functionality (parsers) may encounter performance issues or run out of file descriptors. This may occur because XML parser instances are bootstrapped by doing a lookup in the jaxp.properties file (JAXP API). Oracle recommends setting the properties on the command line to avoid unnecessary file operations at runtime and improve performance and resource usage.
Follow JWS Programming Best Practices in Getting Started With WebLogic Web Services Using JAX-WS.
Follow best practice and tuning recommendations for all underlying components, such as Tuning WebLogic Server EJBs, Tuning Web Applications, Tuning JDBC Applications, and Tuning WebLogic JMS.

Tuning Web Service Reliable Messaging Agents

Web Service Reliable Messaging provides advanced store-and-forward capability for high-performance message forwarding from a local server instance to a remote destination. See “ Understanding the Store-and-Forward Service” in Configuring and Managing WebLogic Store-and-Forward. The following section provides information on how to get the best performance from Store-and-Forward (SAF) applications:

Configure separate SAF Agents for JMS SAF and Web Services Reliable Messaging Agents to simplify administration and tuning.
Sharing the same WebLogic Store between subsystems provides increased performance for subsystems requiring persistence. For example, transactions that include SAF and JMS operations, transactions that include multiple SAF destinations, and transactions that include SAF and EJBs. See Tuning the WebLogic Persistent Store.
Consider increasing the WindowSize parameter on the remote SAF agent. For small messages of less than 1K, tuning WindowSize as high as 300 can improve throughput.

Note: Note that WindowSize also tunes JMS SAF behavior, so it may not be appropriate to tune this parameter for SAF agents of type both.

Ensure that retry delay is not set too low. This may cause the system to make unnecessary delivery attempts.

Tuning Heavily Loaded Systems to Improve Web Service Performance

The asynchronous request-response, reliable messaging, and buffering features are all pre-tuned for minimum system resource usage to support a small number of clients (under 10). If you plan on supporting a larger number of clients or high message volumes, you should adjust the tuning parameters to accommodate the additional load.

Setting the Buffering Sessions

The reliable messaging and buffering features use JMS queue sessions to send messages to the reliability/buffer queues. By default, WebLogic Server allocates 10 sessions for buffering which enables 10 clients to enqueue messages simultaneously onto the reliability/buffer queue.

Note that for asynchronous request-response, the request and response portion of the communication exchange count separately, as two clients. In this case, the default pool of sessions can support five simultaneous asynchronous request-response clients. To accommodate the number of concurrent clients you expect in your application, set the following parameter to twice the number of expected client threads:

Releasing Asynchronous Resources

When using the asynchronous request-response feature, WebLogic Server persistently stores information about the request until the asynchronous response is returned to the client. These resources remain in the persistent store until they are released by a background thread, called the store cleaner.

Often, these resources can be released sooner. Executing the store cleaner more frequently can help to reduce the size of the persistent store and minimize the time required to clean it.

By default, the store cleaner runs every two minutes (120000 ms). Oracle recommends that you set the store cleaner interval to one minute (60000 ms) using the following Java system property: