This chapter describes Oracle best practices for designing, developing, and deploying WebLogic Web Services applications and application resources in WebLogic Server 10.3.6.
This chapter includes the following topics:
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-style & encoding for your Web service application.
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 for minimum performance overheads.
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 Transactions.
Use replication and caching of data and schema definitions to improve performance by minimizing network overhead.
Consider any XML compression technique only when XML compression/decompression overheads are less than network overheads involved.
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 JAX-WS Web Services for Oracle WebLogic Server.
Follow best practice and tuning recommendations for all underlying components, such as Tuning WebLogic Server EJBs, Tuning Web Applications, Tuning Data Sources, and Tuning WebLogic JMS.
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 Store-and-Forward for Oracle WebLogic Server. 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:
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.
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, as described in the following sections:
Define a Work Manager and set the thread pool minimum size constraint (min-threads-constraint) to a value that is at least as large as the expected number of concurrent requests or responses into the service.
For example, if a Web service client issues 20 requests in rapid succession, the recommended thread pool minimum size constraint value would be 20 for the application hosting the client. If the configured constraint value is too small, performance can be severely degraded as incoming work waits for a free processing thread.
For more information about the thread pool minimum size constraint, see "Constraints" in Configuring Server Environments for Oracle WebLogic Server.
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.
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:
-Dweblogic.wsee.buffer.QueueSessionPoolSize=size
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:
-Dweblogic.wsee.StateCleanInterval=60000