WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios

40 WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios

2.4 Best practices considerations

Q Capture, Replication queue map, Q Apply, and WebSphere MQ provide a

number of parameters to optimize the operation and performance of the Q

replication environment. Each of the main parameters associated with these

components is discussed in the following sections. A brief description of each

parameter function, and its key considerations and best practices

recommendations is provided. Since latency is a critical criterion in the selection

of Q replication as the technology to address business requirements, it is

specifically addressed here.

2.4.1 Q Capture considerations

The Q Capture program’s operating parameters govern the way that it starts, the

amount of memory that it uses, which queue manager it connects to, and how

frequently it commits messages to queues, amongst other things. The

parameters are read from the IBMQREP_CAPPARMS table when Q Capture is

started or re-initialized. One can specify temporary runtime values for some

parameters when the program is started, and also while the program is running.

The main parameters of interest discussed here are COMMIT_INTERVAL,

MEMORY_LIMIT, MONITOR_INTERVAL, and SLEEP_INTERVAL.

COMMIT_INTERVAL

This parameter specifies how often, in milliseconds, a Q Capture program

commits transactions to WebSphere MQ. By default, a Q Capture program waits

500 milliseconds (a half second) between commits. At each interval, the Q

Capture program issues an MQCMIT call. This signals the WebSphere MQ

queue manager to make messages that were placed on send queues available

to the Q Apply program or other user applications. All of the DB2 transactions

that are grouped within an MQCMIT call are considered to be a WebSphere MQ

unit of work, or transaction. Typically, each WebSphere MQ transaction contains

several DB2 transactions.

The default COMMIT_INTERVAL value is 500 milliseconds. Committing

messages more frequently requires more CPU usage and I/O overhead.

Lowering the commit interval value is not likely to improve throughput, but will

potentially improve latency. If you cannot increase the amount of memory

(MEMORY_LIMIT) allocated for the Q Capture, then you can reduce the commit

interval. Reducing the commit interval flushes messages from memory more

often and prevents the Q Capture program from spilling transactions to disk.

Raising the commit interval reduces CPU usage, which may be appropriate in a

low volume environment, but can increase latency.