© Copyright International Business Machines Corporation 2003. All rights reserved.
IBM ® WebSphere® MQ Integrator message flows process messages at different rates. This happens because of a number of factors, such as the message flow design, implementation of the design, configuration of the message broker environment, and the hardware on which the broker is implemented.
This article offers recommendations for configuring and tuning a WebSphere MQ Integrator broker and related components in order to maximize the rate at which messages can be processed. It also examines the type and speed of hardware that you should use. The information in this article applies to brokers in both WebSphere MQ Integrator and WebSphere MQ Integrator Broker, but for simplicity, both products are collectively called WebSphere MQ Integrator.
This article assumes that you are familiar with the configuration of WebSphere MQ Integrator and any associated WebSphere MQ queue managers, therefore, it does not cover the detailed configuration of these components.
To improve the rate of message processing, you can tune any of the following WebSphere MQ Integrator components:
- Broker queue manager and any connected queue managers
- Broker
- Databases used to hold broker and business data
The following table summarizes the options you have on each operating system for tuning these components. The details and recommendations for each option are presented in this order.
| Tuning Option | Component | AIX® | Solaris | HP | z/OS | Windows® 2000/NT® |
| Topology of WebSphere MQ components | Queue manager | Y | Y | Y | Y | Y |
| Trusted channel and listener | Queue manager | Y | Y | Y | N | Y |
| Queue manager logging | Queue manager | Y | Y | Y | Y | Y |
| Trusted broker | Broker | N | Y | Y | Y | Y |
| Multiple instances | Broker | Y | N | Y | Y | Y |
| Multiple execution groups | Broker | Y | Y | Y | Y | Y |
| Open handle cache | Broker | N | Y | Y | Y | Y |
| Shared library support | Broker | N/A | N/A | N/A | Y | N/A |
| Trace | Broker | Y | Y | Y | Y | Y |
| Trace | Database | Y | Y | Y | Y | Y |
| Log and data I/O time | Database | Y | Y | Y | Y | Y |
| Broker database | Database | Y | Y | Y | Y | Y |
| Business database | Database | Y | Y | Y | Y | Y |
This article uses the term Windows to mean both the Windows 2000
and Windows NT operating systems. And, it uses the term UNIX to
collectively refer to the AIX, Solaris, and HP-UX operating systems.
The WebSphere MQ Integrator broker is dependent on the performance of its associated queue manager for the efficiency of the MQ API requests, which are issued within a message flow. There are a number of factors which determine the performance of that queue manager and you can affect them by tuning the topology of the WebSphere MQ components, the channels and listeners, and the queue manager logging.
Topology of WebSphere MQ components
Input messages for a message flow are generated by an application and, similarly, the output messages from the message flow are consumed by an application. It is possible that the same applications could both generate and consume messages.
There are three possible configurations with the broker queue manager and these applications:
- Applications and broker queue manager are located on the same system.
- Applications connect to a queue manager which is remote from the broker queue manager. Input messages for the message flow arrive over a WebSphere MQ channel. Similarly the output messages will leave over a channel.
- WebSphere MQ Client applications connect to the broker queue manager.
Each of these configurations requires a different amount of processing in order to process messages. The fewer queue managers that input and output messages have to traverse the cheaper the cost of processing the messages and therefore the higher the message rate that can be obtained. For examples, configuration 1 requires less processing than configuration 2, as the messages will already be in the required queue manager.
In more complex environments, it is the collective efficiency of the components which determines overall performance. You might need to examine the configuration and tuning of connected managers when trying to optimize the throughput of your Integrator Broker
Trusted channel and listener
On Windows, Solaris, and HP-UX, it is possible to run both the broker queue manager channel and listener in trusted mode. This significantly reduces the cost of processing messages. However, the use of a trusted channel and listener is only recommended in a stable environment because the level of protection between the channel or listener and the queue manager is reduced
This option is not used on the z/OS operating system.
Queue manager logging
The efficiency of logging can have a significant effect on the rate at which messages can be processed. When processing persistent messages, a WebSphere MQ queue manager must log the messages as they are created and updated. This involves synchronous writes to the queue manager log at the point at which the message processing for the message flow is to be committed.
Synchronous writing to the log makes the speed of the I/O important, therefore it is preferable to use a write cache for the disks on which the log is located. When using a write cache, the time it takes to complete the I/O will be equal to the time it takes to write to the cache. Copying the data from the cache to the disk will be managed by the disk subsystem. The cache must be nonvolatile to ensure that log data is protected in the event of a catastrophic failure, such as loss of power.
Because writing to the cache is significantly faster than writing directly to the disk, it will be possible for you to achieve a significantly higher message rate when processing persistent messages. Writing to a cached disk can mean that a log I/O operation can be completed in 1 millisecond instead of the 8-10 milliseconds that it might take for a standard SCSI disk. On Windows and AIX, write cache is available through the use of SSA disks with a fast write nonvolatile cache. To achieve the same effect on z/OS, use a device such as the ESS 2105-E20 DASD subsystem with Feature 2121. An alternate approach is to use Solid state disks.
Configuration of the queue manager log varies by operating system.
Windows and UNIX operating systems
On Windows and UNIX systems, it is possible to control:
- The maximum size of a write to a log extent
- The size of a log extent
- The number of log extents
- The location of the log
- Whether to use circular or linear logging
Values that control the configuration of the queue manager log
are specified within the log stanza in the registry on Windows,
and in the qm.ini file of the queue manager on the
UNIX operating systems.
The most important of these values are the maximum size for writing to a log extent and the location of the log. In order to increase the amount of data that can be written and reduce the amount of switching between log extents, use values at the upper end of the range. It is also recommended that you locate the queue manager log on its own disk.
z/OS operating system
On the z/OS, you can control:
- The size of the active log data sets
- How many active log data sets are defined
- The location of the active logs
- The location of the archive logs
- Whether to use single or dual logging
The most important of these values is the location of the active logs. You should ensure that the logs are located on disks that have low utilization.
Regardless of the operating system your queue manager runs on, you should ensure that the performance of logging is efficient. You do not want your Integrator Broker queue manager or any connected queue manager to be continuously switching between log extents or archiving logs. However, it is important that switching does occur on a regular basis so that log data is archived. This will reduce the amount of time it takes to recover in the event of failure.
The configuration of the WebSphere MQ Integrator broker and the manner in which message flows are assigned can have a noticeable effect on message throughput.
Trusted Broker
On Windows, Solaris, and HP-UX, it is possible to run the broker as a trusted application. When the broker runs as a trusted application, WebSphere MQ API calls are processed more efficiently. Trusted applications are a WebSphere MQ concept. By default, a WebSphere MQ Integrator broker does not run as a trusted application.
- To define a broker as a trusted application, use the
-tflag on themqsicreatebrokercommand. - To modify an existing broker to make it trusted, use the
-tflag on themqsichangepropertiescommand. - To change a trusted broker back to standard mode, use the
-nflag on themqsichangepropertiescommand.
As with trusted channels and listeners, using a trusted broker is only recommended in a stable environment. There is the potential to compromise the integrity of the queue manager (for example, with a badly written plug-in node).
Multiple instances
If you have a requirement to run multiple copies of message flow within a broker, use additional instances of the message flow within an execution group. This is works on all operating systems except Solaris. On Solaris,use up to two copies of a particular message flow within an execution group (That is one additional instance of the message flow). If greater message throughput is required for that message flow, use multiple execution groups each with two copies of the message flow. Each additional instance of a message flow is implemented as an operating system thread on Windows and UNIX, or as a Task Control Block (TCB) on z/OS. Each additional instance has the potential to use an additional processor.
Multiple execution groups
It is possible to assign a message flow to one or more execution groups. An execution group provides separation at the process level on the Windows and UNIX systems, and at the address space level on z/OS. Each additional execution group has the potential to use an additional processor.
Open handle cache
Each execution group has a cache of open WebSphere MQ queues handles, with a default size of 30. In some situations, it might be necessary to increase the size of the cache. For instance, when:
- There are many message flows assigned to an execution group and it is likely that there will be more than 30 queues concurrently being written or read
- Publish/Subscribe is used and there are likely to be more than 30 output queues for subscribers in a single publish activity.
You should increase the size of the cache to a
value that is grater than the typical number of queues which are
being read and written. To change the cache size, use the mqsichangeproperties
command. The way to run the command varies with operating system.
On the Windows and UNIX systems, you can run the command from a
command line or shell prompt. On z/OS, you must run a batch job.
Shared library support
On Windows and UNIX systems, the libraries which are shipped as part of WebSphere MQ Integrator are shared by default. On z/OS, by default, each address space will load a copy of the libraries, which leads to an increased demand for real storage. Therefore, on z/OS, it is recommended that you implement shared library support so that WebSphere MQ Integrator DLLs are shared across address spaces.
Trace
Because the overhead to run trace is significant, it is important to ensure that all tracing is turned off when you are not debugging problems. The key WebSphere MQ Integrator related traces are the WebSphere MQ Integrator product trace (user and system) and ODBC trace.
To ensure that all tracing within WebSphere MQ
Integrator is switched off, use the mqsichangetrace
command with a level of none. Remember to do this for
all execution groups. Also, ensure that there are no trace nodes
in the processing paths of your message flows. When a trace node
is invoked, it results in a processing overhead even if it does
not write trace data.
The method to turn off ODBC trace varies by operating
system. On Windows, you control ODBC trace using the tracing tab
of the ODBC function, which is available in the Control Panel. On
UNIX, you control it through the Trace keyword of the
odbc.ini file. Possible values are 0 (off)
and 1 (on). On the AIX, the trace file is located in
/var/wmqi/odbc/.odbc.ini. On Solaris and HP-UX, it
is in /opt/wmqi/merant/odbc.ini. On the z/OS, you control
ODBC tracing by setting the APPLTRACE keyword in the
DSNAOINI file in the broker's (HFS) file system. Possible
values are 0 (off) and 1 (on).
You should also check for other product or system-related traces, such DB2® trace or AIX system trace, which might have been used during message flow development.
Database tuning can have a significant effect on message throughput depending on the composition of the message flow. There are a number of things that you can do to improve the efficiency of this processing, such a turning trace off, minimizing log and data I/O time, and tuning the databases.
Trace
Whenever possible, ensure that all database tracing is turned off. When you must use it, ensure that the minimum level necessary, such as accounting trace, is enabled.
Log and data I/O time
Database update operations (such as update, insert, and delete) all benefit when the database log is located on a fast device, such as a disk with a fast write nonvolatile cache. This is because these update operations require synchronous writing to the database log. The faster that this writing takes the place, the higher the message throughput.
In general, when update operations are performed in a relational database to data that is not of type BLOB, the data is buffered and the physical write of the data to disk is deferred until a checkpoint takes place within the database manager. In this situation, the speed of I/O for the database data is not as important as the speed of the device on which the log is located. When BLOB data is written to a database, the data is not buffered but is written straight to disk, making the speed of the disk on which the data is located important. In this case, using a fast device, such as one with fast write nonvolatile cache, will optimize performance
Broker database
There is limited potential for tuning the broker database unless you have one or more of the following situations:
- Subscribers are registering or deregistering for Publish/Subscribe
- Retained publications are in use
- Aggregate nodes are in use
In all cases, it is recommended that you ensure that the broker database log is located on a fast nonvolatile device, since there will be insertion of data.
Business database
Message flows which access and update business data in a database can significantly benefit from database tuning. Following are some recommendations. Your database administrator should also review the performance of all aspects of the database.
- Where there is read activity against a database table, ensure
that bufferpools are of an adequate size to provide a good hit
ratio for data and index reads.
- Where activity against a table is read-only, consider creating
a read-only view of the table. The view can be referenced in the
message flow in the same way as the original table. This will
reduce the amount of locking that the database manager has to
perform and result in better read performance.
- Consider the use of indices on database tables that have many rows.
WebSphere MQ Integrator uses Dynamic SQL to process each of the database calls within a message flow. It is desirable to reuse statements whenever possible. To make this happen:
- Enable dynamic statement caching within your database (assuming it is supported).
- Check that all ESQL PASSTHRU statements in your message flows use substitution variables.
The activation of dynamic statement caching will
vary with database and operating system. With DB2, for example,
caching is enabled by default on the Windows and UNIX systems. It
is not enabled by default on z/OS. To enable it on z/OS, specify
the DB2 zparm parameters CACHEDYN=YES and EDMDSPAC=81920.
You should also monitor the efficiency of caching.
Check that the cache size is sufficiently large and that the cache
hit ratio is high for each of the dynamic SQL statements being executed.
With DB2 on Windows and UNIX systems, you can monitor cache utilization
with the db2 get snapshot commands. On z/OS, use the
dynamic Statement Cache Statistics in the DB2 Statistics Trace,
which is produced by DB2PM Statistics.
The broker has excellent potential for using a multiprocessor system, as the message flow architecture supports multiple threads (or TCBs), processes, or address spaces, depending on the operating system. Whether or not this is achieved depends on the processing characteristics of the message flow and the number of copies of the message flow that are running. It is important to use fast processors, as most message flows typically have a significant amount of CPU-based processing.
Even when processing is predominantly CPU-bound, it is still possible to have throughput constrained by I/O. In such cases, you will need to either reduce the amount of I/O that is performed, or decrease the time taken to perform it. Ideally, you want to allow for this in the original system specification.
When messages are large ( megabytes rather than kilobytes), memory requirements can be significant. Processing large messages tends to be more complex. Typically, large messages are composed of multiple smaller messages, which have to be processed individually. The working set of message flows can be substantial and, consequently, so might the amount of physical memory that is required. This is difficult to predict in advance and is best to identify it with early testing of the actual message flow. The precise requirements for the broker machine will depend heavily on the number of message flows, their complexity, and the target message rate.
If you are running MQSeries 5.2 for z/OS, apply PTFs UQ56617 and UQ65377.
If you are running MQSeries Integrator V2.0.2 on Windows or UNIX systems and are using the MRM, ensure that CSD2 is installed. It contains a fix for an MRM performance problem.
This article examined the major issues to address when tuning your WebSphere MQ Integrator broker and offers many recommendations for improving the rate at which messages can be processed. It also looked at the environment in which the broker runs.
This article shows you that efficient message processing involves more than just tuning the WebSphere MQ Integrator broker. You must also consider any connected queue managers and database managers. As with message flow design and implementation, there is no single issue that controls performance. It is important that you address all of them.
- WebSphere
Business Integration Zone
- WebSphere
MQ Integrator for z/OS V2.1 Implementation Guide
-
Business Integration Solutions with MQSeries Integrator
Tim Dunn is a Senior Performance Specialist with the WebSphere MQ Integrator performance team in IBM Hursley. Tim works with development in evaluating new releases of WebSphere MQ Integrator and with leading customers to provide consultancy on design, configuration, and tuning issues relating to WebSphere MQ Integrator. Tim has presented on WebSphere MQ Integrator performance in the United States and Europe. He has also authored a number of articles on improving the efficiency of a WebSphere MQ Integrator implementation. You can reach Tim Dunn at: dunnt@uk.ibm.com .
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
