Message Rates

Message rate is the simplest performance number in IBM MQ: how many puts, gets, or channel transfers happen each second. Operations teams quote it in war rooms; capacity planners graph it by month; developers ask whether a new feed will fit. Yet beginners often measure only one side of the pipe—MQPUT returns from producers—while consumers lag and queues deepen. Message rate without queue depth context misleads. This tutorial defines put rate, get rate, net rate, and channel rate; explains how to collect them on distributed and z/OS queue managers; contrasts average, peak, and sustained rates; ties rates to throughput and latency; and shows alerting patterns so you detect spikes before MAXDEPTH stops the business.

Types of Message Rates

Put rate and get rate should be measured on the same queue or logical flow. If ORDERS.IN receives five thousand puts per second but only four thousand gets per second, net rate is plus one thousand messages per second accumulating on the queue—roughly sixty thousand per minute unless something changes. Channel rate measures messages crossing a sender channel, which may differ from local put rate when batching, compression, or multiple queues feed one XMITQ.

Collecting Rates Manually

Sample DISPLAY QLOCAL CURDEPTH and IPPROCS/OPPROCS at time T0 and T1. For rough put/get balance, some monitors use accounting messages or statistics. For channels, note MSGS from DISPLAY CHSTATUS at two timestamps one minute apart; divide delta by sixty for per-second rate. Use consistent intervals—one second sampling is noisy; sixty seconds smooths spikes but hides sub-minute bursts. Production monitoring agents usually poll every fifteen to sixty seconds.

1
2
3
4
5
6
7
8
9
* Snapshot 1
DISPLAY QLOCAL('PAYMENT.IN') CURDEPTH
DISPLAY CHSTATUS('TO.BANK') MSGS BYTSC
 
* Wait 60 seconds
 
* Snapshot 2 — same commands
* Channel msg/s ≈ (MSGS2 - MSGS1) / 60
* If CURDEPTH rose by 6000 in 60s and gets flat, net +100 msg/s

Statistics and Accounting

IBM MQ can emit statistics records and accounting data when configured—queue manager and queue-level counters for opens, puts, gets, and failures. Enabling statistics has CPU overhead; tune intervals per IBM documentation for your release. Export to Prometheus, Splunk, or Instana via agents. Statistics help historical peak analysis better than manual DISPLAY alone. Accounting ties rates to application user IDs when CONNAUTH maps identities—useful for chargeback and finding a noisy neighbor application.

Average Versus Peak Versus Sustained

Average message rate over twenty-four hours hides the ten-minute payroll spike that fills queues. Peak rate is the maximum observed in the window—size disks and consumers for peak times burst factor. Sustained rate is peak held for minutes or hours—stress tests and Black Friday. Document which number you give to infrastructure: saying four thousand msg/s without qualifying average or peak causes undersized DR sites.

Rates Across the Architecture

• Local queue: put and get rates on QLOCAL directly reflect application load.
• Transmission queue: put rate from applications via remote queue defs; drain rate equals channel MSGS when channel healthy.
• Cluster: aggregate rates per cluster queue or per queue manager member in QSG.
• Pub/sub: publish rate to topic; separate subscriber delivery rates per subscription queue.

Persistence Mix and Rate Reporting

Persistent messages cost more per operation than non-persistent. When reporting four thousand msg/s, state how many are persistent. A sudden drop in achievable put rate after enforcing persistence on a queue is expected—not necessarily a regression. Compare like with like in before-and-after tuning tests.

Alerting on Message Rates

1. Put rate exceeds historical peak by fifty percent for fifteen minutes—investigate new release or duplicate producer.
2. Get rate drops to zero while put rate continues—consumer failure or deployment.
3. Channel MSGS rate zero while XMITQ CURDEPTH rises—channel stopped or binding.
4. Byte rate spikes with flat message count—larger messages or attachment growth.

z/OS Notes

Queue sharing groups share queues in the coupling facility; message rates may be aggregated across members serving the same queue name. SMF type 115 and MQ accounting on z/OS provide member-level detail. CF structure contention can cap achievable rate below distributed benchmarks—use platform-specific baselines.

Tutorial: Build a Rate Dashboard Row

For each critical queue, chart four series: put rate, get rate, CURDEPTH, and net rate derived. Add channel MSGS rate for associated SDR. During incident, net rate near zero with stable depth means balance; positive net rate with rising depth means scale consumers or throttle producers.

Explainer: Cars Per Minute

Message rate counts how many cars pass a checkpoint per minute. Throughput also asks how many passengers (bytes) move. If more cars enter a parking lot than leave, the lot fills even when entry rate is impressive.

Explain Like I'm Five

Message rate is counting how many marbles drop into a jar each second and how many come out. If more go in than out, the jar gets full—that number per second is what grown-ups watch on graphs.

Practice Exercises

Exercise 1

MSGS rises from 1,200,000 to 1,203,600 in sixty seconds. Calculate channel message rate.

Exercise 2

Put rate 5,000/s, get rate 4,200/s. How many messages accumulate in five minutes?

Exercise 3

Design three alerts for PAYMENT.IN using put, get, and depth.

Frequently Asked Questions

Test Your Knowledge