You can change the integration server 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 by
creating multiple record and replay stores.
About this task
You can modify the server.conf.yaml file to tune recording for your
integration server. See Configuring data recording.
Consider each of the following
factors of a record and replay store when designing your integration server configuration for record
and replay.
- threadPoolSize
- This property of a record and replay store determines the number of threads that are used by the
recorder to process the monitoring topic subscriptions. The default value is 10.
- commitCount
- The commitCount property of a record and replay store 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.
- commitIntervalSecs
- The commitIntervalSecs property of a record and replay store 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.
- storeMode
- The storeMode property of a record and replay store sets the mode for the store
to operate in. Valid values are record, view, and
all. The default value is all, meaning that you can record, view,
and replay the data. You can spread workload by specifying multiple stores with different
integration servers for recording and viewing data specified for each one.
- record and replay stores and record and replay sources
- The relationship between record and replay stores and record and replay sources is one-to-many.
To use multiple sources for storing recorded data, you can define several sources. To increase the
number of integration servers and queues used to process data for recording and viewing, you can
change the ratio of sources to stores. For more information, see Using multiple integration nodes and multiple independent integration servers for record and replay.
- queue Name and backoutQueue
- The queueName property of a record and replay store specifies the queue that is
used for holding data before it is recorded. The backoutQueue property of a record
and replay store 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. The same backoutQueue can be specified for multiple record replay
stores.
You can configure IBM® MQ to warn when queue depths are
close to their maximum size. For more information, see the topics about Event monitoring
in
the
IBM MQ
documentation.
You can also increase the maximum queue depth
and the maximum message length for queues by using 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