To help optimize performance, you can set tuning properties
that control the performance of message-driven beans and other messaging
applications.
About this task
To optimize the performance of messaging with the default
messaging provider, you can use the administrative console to set
various parameters. You can also set these parameters by using the
wsadmin tool.
On z/OS®,
the performance of messaging applications is affected by the number
of servants, which can vary dynamically, and the distribution of work
between servants. For more information about configuring and managing
the number of servants and the distribution of work between servants,
see Tuning the application serving environment.
Procedure
-
Monitor MDB thread pool size for the default messaging provider.
You might experience a performance bottleneck if there are insufficient threads available for the
message-driven beans. There is a trade-off between providing sufficient threads to maximize the
throughput of messages and configuring too many threads, which can lead to CPU starvation of the
threads in the application server. If you notice that the throughput for express nonpersistent,
reliable nonpersistent, or reliable persistent messaging has fallen as a result of increasing the
size of the SIBJMSRAThreadPool thread pool, then decrease the size of the
thread pool and reassess the message throughput.
-
View or change the number of threads in the default thread pool for an application
server.
By default, message-driven beans use the
SIBJMSRAThreadPool thread pool.
- Click . By default the Minimum size value is set to 35 and the Maximum size value is set to
41.
- Change the Maximum size value, then click OK.
- Optional:
Create your own thread pool.
The default thread pool is also used by other
WebSphere Application Server
components, so you might want to define a separate thread pool for the message-driven beans. This
reduces thread contention for the default thread pool.
- Click .
- Create a new thread pool.
- Create sufficient threads to support the maximum amount of concurrent work for the
message-driven beans.
- Change the SIB JMS Resource Adapter to use the new thread pool:
- Click .
- If you cannot see any SIB JMS Resource Adapter instances in the list, expand
Preferences and enable Show built-in resources.
- Select the SIB JMS Resource Adapter with the appropriate scope depending
upon the scope of the connection factories.
- Add the name of the new thread pool in the Thread pool alias box.
- Click Apply .
-
Save your changes to the master configuration.
-
Tune MDB performance with the default messaging provider.
-
Click .
-
Set the maximum batch size for this activation specification.
Delivering batches of messages to each MDB endpoint can improve performance, particularly when
used with Acknowledge mode set to Duplicates-ok auto-acknowledge
. However, if
message ordering must be retained across failed deliveries, set this parameter to 1.
-
Set the maximum number of concurrent endpoints for this activation specification.
The maximum concurrent endpoints parameter controls the amount of concurrent work that can be
processed by a message bean. The parameter is used with message-driven beans. Increasing the number
of concurrent endpoints can improve performance but can increase the number of threads in use at one
time. To benefit from a change in this parameter, there should be sufficient threads available in
the MDB thread pool to support the concurrent work. However, if message ordering must be retained
across failed deliveries, set this parameter to 1.
-
Save your changes to the master configuration.
-
Change the maximum connections in a connection factory for the default messaging provider.
The maximum connections parameter limits the number of local connections. The default is 10. This
parameter should be set to a number equal to or greater than the number of threads (enterprise
beans) concurrently sending messages.
-
Click .
-
Enter the required value in the Maximum connections field.
-
Click Apply.
-
Save your changes to the master configuration.