IBM Integration Bus, Version 10.0.0.1 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Tuning data capture

You can change the integration node configuration to improve performance and message throughput when you are recording data. You can configure the number of integration servers and queues used to process the data, the size of the thread pool that is used by each integration server, and how often data is committed. You can also use more than one database for storing data.

About this task

Consider each of the following factors when designing your integration node configuration for record and replay. For further information about the DataCaptureStore configurable service properties, see DataCaptureStore configurable service.
threadPoolSize
This property is set on the DataCaptureStore configurable service. The property determines the number of threads that are used by the integration server specified in the egForRecord property to process subscriptions to the monitoring topic.
commitCount and commitIntervalSecs
These properties are set on the DataCaptureStore configurable service. The commitCount property identifies the number of input messages that are processed on each thread before a sync point is taken. Decreasing the value of commitCount can improve performance. The commitIntervalSecs identifies the time interval at which a commit is taken when the commitCount property is greater than 1 but the number of messages processed has not reached the value of the commitCount property. Increasing the value of commitIntervalSecs can improve performance.
egForRecord and egForView
These properties are set on the DataCaptureStore configurable service. You can spread workload by specifying multiple data capture stores with different integration servers for recording and viewing data specified for each one.
DataCaptureStore and DataCaptureSource configurable service instances
The relationship of the DataCaptureStore configurable service to the DataCaptureSource configurable service is many to one. To use multiple data sources for storing recorded data, you can define several DataCaptureSource configurable services. To increase the numbers of executions groups and queues used to process data for recording and viewing, you can change the ratio of DataCaptureStore to DataCaptureSource configurable services.
queueName and backoutQueue
These properties are set on the DataCaptureStore configurable service. The queueName property specifies the queue that is used for holding data before it is recorded. The backoutQueue property specifies the queue that is used for backing out messages that cannot be processed. You can use the default queues or you can create new queues so that the data is spread across multiple queues.

You can configure WebSphere® MQ to warn when queue depths are close to their maximum size. For more information, see the WebSphere MQ documentation about "Event monitoring" on the WebSphere MQ Library web page.

You can also increase the maximum queue depth and the maximum message length for queues by using the runmqsc command.

To use the runmqsc command, complete the following steps.

  1. At a command prompt, enter the following command, where qmName is the name of your queue manager:
    runmqsc qmName
  2. Confirm the current settings for your queue by running the following command, where qName is the name of the relevant queue; for example, SYSTEM.BROKER.DC.RECORD. If your queue name contains lowercase characters, you must enclose the queue name in single quotation marks.
    dis qlocal(qName) maxdepth,maxmsgl
  3. Enter the following command, where qName is the name of your queue, newMaxDepth is the new setting for maximum queue depth, and newMaxMsgL is the new setting for maximum message length:
    alter qlocal(qName) maxdepth(newMaxDepth) maxmsgl(newMaxMsgL)
  4. To exit the runmqsc environment, type end.

bj23660_.htm | Last updated 2015-05-28 20:52:46