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.
- 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.