The performance of an IBM WebSphere MQ queue is
highly dependent on the disk performance of the queue manager machine
and the layout of the queue's files on the disk. You should test your
queue with stand-alone utilities so that you have an upper boundary for
the performance that can be expected in a live application.
- Run multiple MQ Receiver tasks.
Run multiple MQ Receiver tasks in parallel on the same machine or
across several machines. The optimal number of MQ Receiver tasks depends
on the transaction type.
NOTE: This guide refers to MQ Receiver, where the actual Siebel Server component you are using may be MQSeries Server Receiver (alias MqSeriesSrvRcvr) or MQSeries AMI Receiver (alias MqSeriesAMIRcvr).The default number of MQ Receiver tasks is 1. You can set this to 10 or more, depending on the nature of your transactions and on available server capacity.
- Run multiple MQ queue managers. If you experience diminishing returns from adding MQ Receiver tasks, you may benefit from running additional MQ queue managers. Doing so can help to reduce contention of MQ resources stored in physical folders on disk.
- Turn off persistent queuing if it is unneeded. Performance issues for nonCPU-bound transactions or for persistent queuing are often related to MQ contention, which is not helped by adding receivers. If you do not require persistent queuing, turn it off.
- Set Maximum Number of Channels parameter. Set the Maximum Number of Channels parameter in the WebSphere MQ queue manager to be greater than or equal to the maximum number of simultaneous clients you have running.
In addition, there are
specific actions you can take to improve WebSphere MQ Transport
performance for outbound and inbound transports, as detailed below.
Inbound Messages
For inbound WebSphere MQ
messages, run multiple MQ Receivers in parallel to increase throughput.
See additional comments earlier in this topic for details.
Outbound Messages (Send, SendReceive)
Caching of WebSphere MQ
Transport business services can improve outbound performance by
eliminating the need to connect to the queue for each message. Caching
is disabled by default because it is not usable in every situation.
Follow these tips to enable caching:
- Cache in client sessions only. Do not use caching if your transport will be called within the Workflow Process Manager (WfProcMgr) component. The threading model of this component is not compatible with the WebSphere MQ APIs.
- To enable caching for a business service, set the Cache property to TRUE in Siebel Tools, then recompile the SRF file.
- If you need to call the WebSphere MQ Transport in Workflow Process Manager and in a client session, make a separate copy of the service (one cached and one uncached) for each situation.
- Caching occurs on a per-queue basis and only one connection is kept open at a time. If a single session is going to talk to multiple queues, consider making a copy of the transport for each outbound queue.
Comments
Post a Comment