WebSphere Message Brokers
File: aq20816_
Writer: Terry Cowling

Concept topic

This build: July 31, 2007 21:35:59

Publish/subscribe performance tuning

WebSphere Message Broker supports up to 25 000 subscriptions on a broker. To handle a large number of subscriptions, you should tune your brokers and the databases that they use. The following sections describe some of the things that you should consider.

Brokers

You might need to change the broker property jvmMaxHeapSize. The default value for this is 128 MB.

The value of this property must be large enough for all topics in the subscriptions. For example, if you have 10 000 subscriptions, each for a topic that uses 20 KB of storage, set the value of the jvmMaxHeapSize property to at least 200 MB.

Use the mqsichangeproperties command to increase the size of jvmMaxHeapSize to 256 MB:
mqsichangeproperties brokername -o ComIbmJVMManager -n jvmMaxHeapSize -v 268435456
where brokername is the name of your broker.
The Configuration Manager uses the list of subscriptions which might be stored on your local hard disk.
  • Windows platform On Windows, the directory is created at C:\Documents and Settings\All Users\Application Data\IBM\MQSI.
  • Linux platform UNIX platform On Linux and UNIX systems, the directory is created at /var/mqsi.
The directory must be at least twice the size of the topic space; that is, for 10 000 subscriptions each using 20 KB, the directory should be at least 512 MB.

Databases

The broker stores its subscription information in its database. You might need to tune your database to handle the maximum 25 000 subscriptions.
  • Windows platform UNIX platform Linux platform Two limits should be noted when using DB2. Both limits affect the ability to successfully restart the broker.
    • The first limit occurs when there are about 1000 subscriptions. The DB2 parameter APP_CTL_HEAP_SZ must be set to a high value to enable the broker to query its database at startup; a value of 8192 is typically large enough for 1000 subscriptions. You can change the value by starting a db2 command prompt, and issuing the command db2 update db cfg using APP_CTL_HEAP_SZ 8192. You might then need to end any connections to the database.
    • The second limit occurs at approximately 8000 subscriptions. When the broker attempts to start, the following error might be reported in the system log:
      Database error: SQL State '54028';
      Native Error Code '-429';
      Error Text '[IBM][CLI Driver][DB2/LINUX] SQL0429N  The maximum number of concurrent LOB locators has been exceeded.  SQLSTATE=54028 '.    
      This error is due to a limitation in the number of LOB handles in DB2. To overcome this problem, you require a patch in DB2; you need to edit file db2cli.ini.

      UNIX platform Linux platform On UNIX or Linux, this file is located in {DB2InstanceHome}/sqllib/cfg/db2cli.ini.

      Windows platform On Windows, this file is located in {Program Files}\IBM\SQLLIB\db2cli.ini.

      Add the following lines to the file:
      [{Database name}]
      PATCH2=50
       LobCacheSize=1048576      
      The PATCH line instructs DB2 to free up LOB locators after it has used them, and the LobCacheSize parameter adjusts the total memory that is available to LOB locators; in this case 1 GB. You might then need to restart the DB2 instance.
  • z/OS platform On z/OS, if you are using DB2 Version 8, a database limit occurs at approximately 15 000 subscriptions. To overcome this, you need to modify the value of NUMLKUS. A value of 20000 should support 25 000 subscriptions.

Collectives

When a subscription is made to a broker that is a member of a collective, or is directly linked to another broker, all brokers that are connected to the broker create a proxy subscription. The total number of proxy subscriptions and direct subscriptions must be less than 25 000 for each of your brokers. This limit has implications on how you plan your broker topology.

For example, consider a collective of N brokers. To maximize connectivity, you connect an instance of a client to each broker with each of those instances subscribing to the same unique topic. Therefore, for N brokers, each unique topic has N clients. In this situation, each broker has a subscription to each client connected to it, and also a proxy subscription to each of the other brokers in the collective. Therefore, each broker has N subscriptions for every unique topic (one for the client that is directly connected, and N-1 for the proxy subscriptions to all of the other brokers). If there are T unique topics, you should make sure that N*T <= 25 000. That is, if you have 1000 unique topics, your collective should be restricted to a maximum of 25 brokers.

Related tasks
Modifying a broker
Configuring databases
Related reference
mqsichangeproperties command
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:35:59

aq20816_ This topic's URL is: