Consider each of the following factors
when designing your broker 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 one to many. 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
You can also increase the maximum queue depth and the maximum message length for queues by using either the runmqsc command or the IBM® Integration Explorer.
WebSphere MQ Library web page.To use the runmqsc command, complete the following steps.
- At a command prompt, enter the following command, where qmName is
the name of your queue manager:
runmqsc qmName - 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 - 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) - To exit the runmqsc environment, type end.
To use the IBM Integration Explorer, complete the following steps.- Under the Queue Managers folder, right-click the queue manager and select Properties.
- In the menu tree, select Extended.
- Edit the values for the Max uncommitted messages or Max message length properties.
- At a command prompt, enter the following command, where qmName is
the name of your queue manager:
Last updated Friday, 21 July 2017