This topic applies only on the z/OS operating system.

Tuning MDB processing on z/OS

To tune MDB processing, you consider and act on a variety of settings together. There is a wide range of values that you can select, and possibilities to consider, because of the variety of workloads possible to run in any given server.

Before you begin

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 WebSphere 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 MDB processing.

About this task

If you want to optimize the processing of messages by message-driven beans, use this task to consider and act on the associated settings.

Tuning MDB processing in the server is a part of the greater task of tuning the server’s entire workload. This needs consideration of a variety of settings and the interactions between those settings.

To tune MDB processing, the following settings must be considered together: WLM service class definitions, WebSphere workload profile selection, Message Listener Service Listener Port settings, JMS Connection Factory pooling settings, and WebSphere MQ Queue Manager settings.

It is difficult to give one recommendation about what values to select for each of these settings, given the variety of workloads possible to run in any given server. There are a wide variety of possibilities to take into consideration, including the following considerations:
  • 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.
  • Different goals regarding the importance of work for message-driven beans relative to other (HTTP, IIOP) types of work running in the server.

The suggested settings below provide a starting point, under the assumption that the server is configured with only a single application consisting of a single message-driven bean installed and running on this server.

The starting point settings are followed by more detailed discussions that 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 understand the function and the settings enough to make your own setting selections for your own systems and servers.

Procedure

  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. To view this administrative console page, click Servers-> Application Servers-> application_server-> [Communications]-> Messaging-> Message Listener Service-> Listener Ports-> listener_port
    2. Set the maximum sessions property to the value you want the MDB 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" as the setting is described 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.

    For further considerations setting the Listener Port maximum sessions property, see Concepts and considerations for MDB settings on z/OS.

  2. Set the WebSphere MQ Queue Connection Factory properties.
    1. To view this administrative console page, click Resources-> WebSphere MQ JMS Provider-> WebSphere MQ Queue Connection Factories (under additional properties)
    2. Select the Connection Factory specified for the Listener Port.
    3. Under the Additional Properties, activate 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 could include message-driven beans mapped onto different listener ports, if those listener ports were each, in turn, mapped onto the same connection factory. For more detailed discussions about considerations that affect this setting, see Concepts and considerations for MDB settings on z/OS.
    5. Under Additional Properties of the Connection Factory, activate 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. This property should be set to at least the number of worker threads available to a single servant. For more detailed discussions about considerations that affect this setting, see Concepts and considerations for MDB settings on z/OS.
  3. Set the WebSphere MQ-related properties. Make sure that 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, you may want to consider your queue manager’s CTHREAD, IDBACK, and IDFORE parameter settings. For more information on these WebSphere MQ settings, see the WebSphere MQ books:
    • WebSphere MQ System Setup Guide (SC34-6052-02).
    • WebSphere MQ Script Command (MQSC) Reference Book (SC34-6055-03)
    • WebSphere MQ Problem Determination Guide (GC34-6054-01).

Example

  1. Suppose your server is configured with the maximum server instances value set to 3, (whatever the minimum number may be). Also suppose that your workload profile is LONGWAIT, which means each servant contains 40 worker threads.

    In this case, set your listener port maximum sessions value to at least 240 = 2 * 3 * 40.

  2. Suppose that your 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 perform this task. Suppose the Administrator has mapped each MDB’s 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, you need to set the connection factory’s 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’s 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 Best practices for debugging MDB throttle support.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=tprf_tunezmdb
File name: tprf_tunezmdb.html