Performance standards for IBM MQ turn vague slow into numbers everyone agrees on: this queue may hold at most fifty thousand messages before page operations, this channel pair must drain the transmission queue within fifteen minutes at peak, this queue manager CPU stays below seventy percent sustained. Without standards, teams debate whether depth ten thousand is normal because it was ten thousand yesterday too—while consumers fell behind after a sale event. Beginners learn MQ objects first; performance engineering asks how those objects behave under load. This tutorial defines enterprise baselines for persistence choices, depth and MAXDEPTH, consumer scaling, channel and log tuning, monitoring KPIs, and capacity review cadence so you can design queues that survive peak day not just demo day.
DEFPSIST(YES) on queues forces persistent messages to survive restart; each put waits for log I/O. DEFPSIST(NO) or non-persistent puts trade durability for speed—appropriate only when loss on failure is acceptable or recovered elsewhere. Standard: default new application queues to persistent in production unless architect sign-off documents otherwise. Non-persistent flood on a shared queue manager can starve disk I/O for persistent traffic—separate queue managers or storage tiers for telemetry if needed.
| Setting | Durability | Performance | Use when |
|---|---|---|---|
| Persistent put | Survives QM restart | Higher latency, log I/O | Payments, orders, audit trail |
| Non-persistent put | Lost if QM fails before delivery | Lower latency | Metrics, discardable telemetry |
| Syncpoint put | With DB commit | Slowest; two-phase | Composite transactions |
MAXDEPTH caps CURDEPTH; when full, puts fail with MQRC 2053 Q_FULL. Standards should define default MAXDEPTH per queue class (interactive, batch, DLQ) and alert thresholds as percentages. A queue with MAXDEPTH 999999 and alert at depth 1000 wastes monitoring signal. Prefer explicit limits that force architectural conversation when exceeded. Triggered consumers help but do not replace capacity planning—triggers add processes and can amplify storms if poison messages loop.
123DEFINE QLOCAL('ORDERS.IN') MAXDEPTH(100000) DEFPSIST(YES) + DESCR('Alert 70%=70000 90%=90000 per perf standard PERF-QUEUE-01') DISPLAY QLOCAL('ORDERS.IN') CURDEPTH IPPROCS OPPROCS
Document minimum consumer instances per queue at peak, expected messages per second per consumer, and maximum processing time per message. Long handlers block the queue even at low depth if each message takes thirty seconds. Use multiple get threads or competing consumers until diminishing returns—then shard into ORDERS.IN.A through ORDERS.IN.D with routing upstream. For JMS, tune session cache and acknowledge mode; for MQI, avoid unnecessary syncpoint per message when batch commit is safe.
Sender channels move messages from XMITQ to partners; insufficient channel instances or low network bandwidth leaves XMITQ depth climbing while applications still put successfully to QREMOTE routes. Standards: define MAXMSGL on channels at least as large as largest message; align both ends; monitor DIS CHSTATUS MSGS. LONGRTT links may benefit from tuning per IBM guidance for your release—test in lab before production. SSL adds CPU; size hosts for TLS handshakes during reconnect storms after outages.
Linear logs on distributed MQ and log streams on z/OS must sit on low-latency storage. Standards include minimum free space, log primary and secondary sizing, and media recovery procedures. Archive log delay causes shutdown risk—not just slow puts. Separate active log volumes from queue data where platform allows. Review log utilization weekly in high-volume systems.
Giant single messages without MAXMSGL review. Unbounded reply queues from dynamic models without cleanup. Browse-heavy monitoring on production queues during peak. Logging every message body at INFO in the application—CPU kills both app and disk. Using SYSTEM.DEFAULT.MODEL.QUEUE in production without limits. Ignoring XMITQ depth because application queue depth looks fine.
Performance standards are speed limits and lane counts. MAXDEPTH is parking lot size at the toll booth. Consumers are toll lanes. Channels are highways between cities. Building a ten-lane highway but one toll lane still backs up traffic.
The toy box has a line drawn inside—if toys pile above the line, grown-ups add more kids to take toys out or get a bigger box before toys spill on the floor.
Define alert thresholds for one payment queue given MAXDEPTH and peak put rate.
Run a load test; graph depth versus consumer count 1, 2, 4, 8.
Find one non-persistent queue in prod catalog; justify or change to persistent.
1. Persistent messages typically:
2. MQRC 2053 means:
3. More consumers on one queue:
4. Performance baseline should include: