In JMeter's JMS Subscriber, what does Number of samples to aggregate change?

middleshould knowfreq 44%

answer

One row can stand for many messages
The clock covers the batch, not a message
Two failure codes, two different stories
404 for none, 500 for not enough

basics

~20 s

Number of samples to aggregate sets how many messages one sample result covers. The sampler keeps reading until it has that many or the Timeout expires, and the elapsed time spans the whole batch, not one message.

solid answer

~50 s

Number of samples to aggregate is the batch size for a single JMS Subscriber sample. Set it to 5 and the sampler loops until it has read five messages or the Timeout (ms) budget runs out — and that timeout is the aggregate budget for the batch, not a per-message wait. The verdict follows the count: zero messages read gives response code 404 and a failed sample; fewer than expected gives 500 and a failed sample; the full count gives 200 and success. The response message spells it out, for example 3 message(s) received successfully of 5 expected. The bodies are concatenated with the Separator field and stored only if Store Response is ticked; otherwise just the length is recorded. The result's own sample count is set to the number actually read, so one row can stand for several messages.

**Number of samples to aggregate** is the batch size for a single JMS Subscriber sample. Set it to `5` and the sampler loops until it has read five messages or the **Timeout (ms)** budget runs out — and that timeout is the aggregate budget for the batch, not a per-message wait. The verdict follows the count: zero messages read gives response code `404` and a failed sample; fewer than expected gives `500` and a failed sample; the full count gives `200` and success. The response message spells it out, for example `3 message(s) received successfully of 5 expected`. The bodies are concatenated with the **Separator** field and stored only if **Store Response** is ticked; otherwise just the length is recorded. The result's own sample count is set to the number actually read, so one row can stand for several messages.

code

text · 9 lines

text

Sampler data:     5 messages expected
Response code:    500
Response message: 3 message(s) received successfully of 5 expected
Successful:       false

Sampler data:     5 messages expected
Response code:    404
Response message: 0 message(s) received successfully of 5 expected
Successful:       false

go deeper

for a junior

Recall that the field batches several messages into one sample, and that a sample failing with 404 or 500 usually means too few messages arrived.

for a middle

Explain that the timeout is the budget for the whole batch and that the response code is chosen from how many messages were actually read.

for a senior

Show the judgment: when a batched drain figure is the honest measurement and when batching destroys the per-message timing you were hired to produce.

for a principal

Decide what a subscriber sample is allowed to mean across a team's plans, so results from different plans can be compared at all.

On an order queue drained by a JMS Subscriber, the single most misread field is Number of samples to aggregate. It sounds like a reporting option. It is not: it changes what one row in your results file is.

What the field actually does

The subscriber runs a read loop. Each pass asks the underlying client for one message; the loop stops when it has read as many messages as the field asks for, or when the sampler's Timeout (ms) budget is exhausted, or when the thread is interrupted. Only when the loop ends does JMeter close the sample and hand over one SampleResult.

Three consequences follow immediately:

Elapsed time spans the batch. A sample that aggregated ten messages measures the time to collect ten, not the time to deliver one. Dividing is not sound either, because the wait between messages is the queue's, not the broker's response.
Timeout is a batch budget. The component reference is explicit: "This is the overall aggregate timeout, not per sample." Set aggregation to 10 and the timeout to 2000, and you have given the subscriber two seconds to find ten messages in total.
One row, several messages. The result's internal sample count is set to the number actually read, so downstream counting does not treat the batch as a single message.

How the verdict is decided

The subscriber sets the response code purely from the count it managed to read:

Messages read	Response code	Sample verdict
`0`	`404`	failed
fewer than requested	`500`	failed
the full requested count	`200`	success

The response message always names both numbers — 3 message(s) received successfully of 5 expected — and the sampler data records 5 messages expected. That pairing is the fastest way to tell a broker that delivered nothing from one that delivered some and ran out of time.

The fields that travel with it

Timeout (ms) — 0 means no timeout, which turns a starved queue into a thread that waits forever. On a load run, always set one.
Separator — the string placed between aggregated message bodies in the response. \n, \r and \t are accepted.
Store Response — unticked, the sampler keeps only the response length instead of the bodies. Useful when the point is drainage rather than content.
Client — MessageConsumer.receive() calls receive for each requested message and does not collect while the sampler is idle, which suits queues. MessageListener.onMessage() installs a listener that keeps banking messages after the sampler finishes, which suits topics.
Stop between samples — ticked, JMeter calls Connection.stop() at the end of each sample and start() before the next; unticked, the connection is started once per thread and stopped at thread end.
Number of samples to aggregate also exists on the JMS Publisher, where it is the number of messages one sample publishes, and on JMS Point-to-Point, where it applies only to the read communication style.

When to raise it above one

Raising it is worth doing when the interesting figure is drain rate rather than per-message latency, or when a listener-based subscription is banking messages faster than a one-at-a-time sampler can consume them. It is the wrong choice when you want per-message timings, because the batching destroys them, and it is a trap when combined with a 0 timeout on a queue that may run dry.

Where it goes wrong

Aggregation left at a high number while the publisher side is slow, so every sample fails on 500 even though nothing is broken.
A 0 timeout with aggregation above 1, producing threads parked on an empty queue for the rest of the run.
Reading the elapsed column as a per-message figure.
Assuming a 404 means the destination was wrong; here it only means no message arrived in time.
Leaving Store Response ticked while aggregating hundreds of messages, so every sample carries a large body.

On an order queue drained by a **JMS Subscriber**, the single most misread field is **Number of samples to aggregate**. It sounds like a reporting option. It is not: it changes what one row in your results file *is*. ## What the field actually does The subscriber runs a read loop. Each pass asks the underlying client for one message; the loop stops when it has read as many messages as the field asks for, or when the sampler's **Timeout (ms)** budget is exhausted, or when the thread is interrupted. Only when the loop ends does JMeter close the sample and hand over one `SampleResult`. Three consequences follow immediately: 1. **Elapsed time spans the batch.** A sample that aggregated ten messages measures the time to collect ten, not the time to deliver one. Dividing is not sound either, because the wait between messages is the queue's, not the broker's response. 2. **Timeout is a batch budget.** The component reference is explicit: *"This is the overall aggregate timeout, not per sample."* Set aggregation to `10` and the timeout to `2000`, and you have given the subscriber two seconds to find ten messages in total. 3. **One row, several messages.** The result's internal sample count is set to the number actually read, so downstream counting does not treat the batch as a single message. ## How the verdict is decided The subscriber sets the response code purely from the count it managed to read: | Messages read | Response code | Sample verdict | |---|---|---| | `0` | `404` | failed | | fewer than requested | `500` | failed | | the full requested count | `200` | success | The response message always names both numbers — `3 message(s) received successfully of 5 expected` — and the sampler data records `5 messages expected`. That pairing is the fastest way to tell a broker that delivered nothing from one that delivered some and ran out of time. ## The fields that travel with it - **Timeout (ms)** — `0` means no timeout, which turns a starved queue into a thread that waits forever. On a load run, always set one. - **Separator** — the string placed between aggregated message bodies in the response. `\n`, `\r` and `\t` are accepted. - **Store Response** — unticked, the sampler keeps only the response length instead of the bodies. Useful when the point is drainage rather than content. - **Client** — `MessageConsumer.receive()` calls receive for each requested message and does not collect while the sampler is idle, which suits queues. `MessageListener.onMessage()` installs a listener that keeps banking messages after the sampler finishes, which suits topics. - **Stop between samples** — ticked, JMeter calls `Connection.stop()` at the end of each sample and `start()` before the next; unticked, the connection is started once per thread and stopped at thread end. - **Number of samples to aggregate** also exists on the JMS Publisher, where it is the number of messages one sample publishes, and on JMS Point-to-Point, where it applies only to the `read` communication style. ## When to raise it above one Raising it is worth doing when the interesting figure is drain rate rather than per-message latency, or when a listener-based subscription is banking messages faster than a one-at-a-time sampler can consume them. It is the wrong choice when you want per-message timings, because the batching destroys them, and it is a trap when combined with a `0` timeout on a queue that may run dry. ## Where it goes wrong - Aggregation left at a high number while the publisher side is slow, so every sample fails on `500` even though nothing is broken. - A `0` timeout with aggregation above `1`, producing threads parked on an empty queue for the rest of the run. - Reading the elapsed column as a per-message figure. - Assuming a `404` means the destination was wrong; here it only means no message arrived in time. - Leaving **Store Response** ticked while aggregating hundreds of messages, so every sample carries a large body.

How does the Client setting change what the JMS Subscriber has collected by the time a sample starts?
`MessageConsumer.receive()` fetches only while the sampler is running, so each sample starts from nothing and races the timeout. `MessageListener.onMessage()` installs a listener that keeps storing arrivals between samples, so a sample can complete instantly from the backlog. The first suits queues, the second suits topics.
What does a Timeout of 0 mean on a JMS Subscriber?
No timeout at all. The read loop then ends only when it has read the requested number of messages or the thread is interrupted, so a thread waiting on an order queue that has run dry will sit there until the test is stopped. On any unattended run, set a real timeout.

saying these in an interview costs you the question

Treating the elapsed time as a per-message latency
Thinking Timeout applies to each message separately
Reading response code 404 as a wrong destination
Leaving Timeout at 0 on an unattended run
Assuming a short batch still counts as a pass

In JMeter's JMS Subscriber, what does Number of samples to aggregate change?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What the field actually does

How the verdict is decided

The fields that travel with it

When to raise it above one

Where it goes wrong

▾common follow-ups2 questions

▾red flags5 flags

What the field actually does

How the verdict is decided

The fields that travel with it

When to raise it above one

Where it goes wrong

answer

go deeper