Throughput

Throughput answers how much messaging work your IBM MQ estate completes in a given second, minute, or batch window. Operations teams promise capacity; architects size hardware; developers ask whether MQ can carry Black Friday traffic. Throughput is not one number for the whole product—it varies by queue manager, queue, channel, persistence choice, message size, TLS, platform, and whether consumers keep up. A hub might sustain fifty thousand small non-persistent pings per second for monitoring yet only two thousand persistent payment messages per second when each put syncs to disk. Beginners confuse high MQPUT return rate with healthy throughput; if CURDEPTH climbs forever, effective throughput to business consumers is zero regardless of put rate. This tutorial defines throughput metrics, walks bottlenecks from disk to application threads, compares persistent versus non-persistent load, explains channel and listener scaling, touches z/OS queue sharing groups, and links throughput to capacity planning without duplicating every tuning page in the Performance section.

Defining Throughput Clearly

Message throughput counts discrete messages: puts, gets, or end-to-end deliveries per second. Byte throughput multiplies message count by average size—important for WAN channels and TLS CPU. Transactional throughput counts committed units of work when applications use syncpoint—one transaction might carry ten messages. State which definition you use in test reports. End-to-end throughput from producer application to consumer application is what the business cares about; channel MSGS only shows movement between queue managers, not slow COBOL consumers.

The Throughput Pipeline

Picture a pipe from producer to consumer: application MQPUT, queue manager log write (if persistent), queue file write, optional channel transmission, remote queue manager receive, target queue, application MQGET. The narrowest section limits throughput—the bottleneck. Speeding up puts while consumers process one message per second only deepens the queue. Performance work identifies the narrow section with data: disk await times, channel batch efficiency, consumer CPU, lock waits on shared queues in QSG.

Persistence and Logging

Persistent messages survive failure because the queue manager forces log records before acknowledging put to the application (subject to MQPMO_SYNCPOINT and options). Disk latency caps persistent throughput. NVMe local disks outperform remote SAN for log volumes. Larger log files reduce archive frequency but do not remove per-message cost. Non-persistent messages skip durable log requirements—higher peaks for telemetry. Mixed estates should separate hot persistent payment queues from high-volume status topics on different queue managers or storage tiers if budgets allow.

Application Design Impact

• Single-threaded consumer: one MQGET loop—simple but caps throughput at one message times loop cost.
• Thread pool consumers: multiple gets on same queue need careful syncpoint and ordering rules.
• Batch get: MQGET multiple messages per call when API allows—reduces per-call overhead.
• Small messages: header overhead dominates; consider combining payloads where format allows.
• Poison messages: redelivery loops waste throughput—configure BOTHRESH and DLQ.

Channels and Network

Sender channels move batches controlled by BATCHSZ and related attributes. Larger batches improve throughput on high-latency WAN by amortizing TCP round trips. Too large batches increase latency for first message in batch—tradeoff. TLS adds CPU; hardware crypto helps. Multiple channels from different XMITQs to same partner can parallelize—coordinate with partner limits. Compress where supported for large XML payloads.

Listeners and Connections

Thousands of short-lived client connections per second stress listeners and CONNAUTH. Connection sharing and reusable client connections improve throughput for Java and .NET clients. On z/OS, channel initiators and dispatchers have limits—DISPLAY QMSTATUS and channel instance counts during peak.

z/OS Queue Sharing Groups

QSG scales throughput by spreading consumers across LPARs against shared queues in the coupling facility. CF structure size and structure locks can become bottlenecks at extreme rates—systems programming tunes CF and buffer pools. Throughput on QSG is often higher than channel-chaining between separate queue managers for same-named queue access.

Capacity Planning Formula (Simplified)

Required sustained throughput equals peak business rate times burst factor (often 1.5 to 3). Message size times rate estimates MB/s for network. Add thirty percent headroom for growth and DR catch-up. If measured consumer throughput is below required, adding producers worsens backlog—scale consumers or partition queues first.

1
2
3
4
5
Example:
Peak = 4,000 msg/s average, 2 KB per message
Bytes/s = 4000 * 2048 = 8.2 MB/s (payload only; headers extra)
Burst factor 2 -> plan 8,000 msg/s (~16 MB/s)
If persistent log disk sustains 12 MB/s write -> bottleneck risk

Tutorial: Find Bottleneck in Four Steps

1. Measure CURDEPTH slope during peak—growing means consumer-limited.
2. Compare put rate from producers versus GET rate from consumers.
3. DISPLAY CHSTATUS for channel MSGS/sec and BATCHSZ effectiveness.
4. Check disk and CPU on log volume during persistent load test.

Explainer: Highway Lanes

Throughput is how many cars pass a checkpoint per minute. More lanes (consumers, batching, faster disk) raise throughput unless the toll booth (one slow consumer) limits everyone.

Explain Like I'm Five

Throughput is how many marbles you can push through a tube in one minute. A wider tube and faster hands push more marbles. If the bucket at the end is tiny and empties slowly, marbles pile up in the tube even if you push fast at the start.

Practice Exercises

Exercise 1

Given 10,000 msg/s puts and 8,000 msg/s gets, describe backlog behavior after ten minutes.

Exercise 2

Estimate MB/s for 5,000 messages of 4 KB each.

Exercise 3

List three changes that raise throughput and one that only raises backlog.

Frequently Asked Questions

Test Your Knowledge