Tune message-driven bean processing on z/OS by using WebSphere MQ as the messaging provider in ASF mode

We can tune message-driven beans processing when we are running WAS on the z/OS platform, where WebSphere MQ is the messaging provider, and the message-driven bean has been deployed in Application Server Facilities (ASF) mode.

To tune message-driven bean processing, we need to consider a variety of settings together. There are a wide range of values and possibilities to consider, because of the variety of workloads possible to run in any given server.

When a message-driven bean is mapped (that is, listening to) a queue, or to a topic through a durable subscription, a JMS message first enters into the application server in the controller, so we say the server is "listening in the controller" for these messages. The "listening in the controller" term is used throughout this description of tuning message-driven bean processing.

When you are tuning message-driven bean processing in the server, we also need to consider the tuning the entire workload for the server, and the interaction between the two.

To tune message-driven bean processing, consider all the following settings together:

• WLM service class definitions

• WebSphere Application Server workload profile selection

• Message listener service listener port settings

• JMS Connection Factory pooling settings

• WebSphere MQ Queue Manager settings

It is difficult to recommend values to select for each of these settings, given the variety of workloads that can be run in any given server. There are many possibilities to consider, including the following factors:

• The number of message-driven beans.

• The administrative configuration choices, such as whether to map two message-driven beans to the same or different listener ports.

• The importance of work for message-driven beans compared with other (HTTP, IIOP) types of work running in the server.

The following suggested settings provide a starting point, and assume that the server is configured with only one application, which consists of a single message-driven bean installed and running on this server.

More detailed discussions explain the rationale behind the suggestions, and describe the listener port function in more detail in the "listening in the controller" case on z/OS. Together, they can help you to make our own setting selections for our own systems and servers.

1. Set the listener port maximum sessions property to at least twice the maximum number of servant worker threads available to the entire server. The value of this property determines the high threshold value (high threshold = maximum sessions), and is used by the throttle to decide when to block or allow requests.

   1. Start the administrative console.

   2. In the navigation pane, click Servers > Server Types > WebSphere application servers->server_name > [Communications] Messaging > Message listener service > [Additional Properties] Listener Ports > listener_port The Message listener port collection panel is displayed.

   3. Select the name of the listener port to work with. The Listener port settings panel is displayed.

   4. Set the maximum sessions property to the value we want the message-driven bean throttle to use as its high threshold value. The suggested minimum value is computed by the formula:
      2 * (maximum number of servants) * (number of worker threads in one servant)

      Here "servants" means the same as "server instances" on the administrative console. To calculate the number of worker threads in a single servant, see the description of "Workload profile" in ORB services advanced settings.

   To learn more about setting the Listener Port maximum sessions property, see the information about message-driven beans and tuning settings on z/OS.

2. Set the WebSphere MQ queue connection factory properties.

   1. To view this administrative console page, click Resources > JMS->Queue connection factories.

   2. Select the queue connection factory specified for the listener port.

   3. From the Additional Properties, select the Connection Pool panel.

   4. Set the Max Connections property for the Connection Pool. Allow one connection for each message-driven bean. This property value might include message-driven beans mapped onto different listener ports, if those listener ports were each, in turn, mapped onto the same connection factory. To learn more about this setting, see the information about message-driven beans and tuning settings on z/OS.

   5. From the Additional Properties of the queue connection factory, select the Session Pool panel.

   6. Set the Max Connections property for the session pool. Allow one session for each worker thread in a single servant. Set this property to at least the number of worker threads available to a single servant. To learn more about this setting, see the information about message-driven beans and tuning settings on z/OS.

3. Set the WebSphere MQ-related properties. Make sure the backing WebSphere MQ queue manager has been configured with enough resources to support the intended JMS workload coming from WebSphere Application Server (and other clients). In particular, consider your queue manager CTHREAD, IDBACK, and IDFORE parameter settings. For more information on these WebSphere MQ settings, see the WebSphere MQ information center.

Example

1. If the server is configured with the maximum server instances value set to 3, (whatever the minimum number might be), and if the workload profile is LONGWAIT (which means that each servant contains 40 worker threads), set the listener port maximum sessions value to at least
   240 = 2 * 3 * 40

2. Suppose that the application contains two individual message-driven beans, each of which has an onMessage() implementation that forwards the message to another JMS destination. Therefore, each message-driven bean needs its own JMS connection factory to complete this task. Suppose the Administrator has mapped each message-driven bean JMS connection factory resource reference onto the same administratively-defined connection factory used by the listener port that each of these message-driven beans is mapped onto.

   In this case, we need to set the connection factory Connection Pool Max Connections value to 42. One connection for each of the two message-driven beans to be used by the listener port, and one connection potentially for each of the 40 onMessage() dispatches that night be running concurrently. (Remember that the connection pool is a per-servant pool).

3. Set the connection factory Session Pool Max Connections to 40, the number of worker threads in a single servant, regardless of the number of servants.

For debugging tips, refer to

Optimizing MDB throttle support for debugging in z/OS.

Related concepts

Message-driven beans and tuning settings on z/OS

Related tasks

Optimizing MDB throttle support for debugging in z/OS

Configure MDB or SCA throttling for the default messaging provider