In JMeter's Asynch sending mode, what happens when the asynch.batch.queue.size queue fills?

## What Asynch changes Under `Standard` and `Batch`, `sampleOccurred` runs on the sampler thread and, when a send is due, that thread makes the RMI call itself. `AsynchSampleSender` breaks that coupling. Its `readResolve` — which runs on the **engine**, as the sender is deserialised — creates an `ArrayBlockingQueue<SampleEvent>` of `asynch.batch.queue.size` entries (default `100`) and starts a daemon `Worker` thread. From then on: 1. the sampler thread calls `queue.offer(e)` and returns immediately when there is room; 2. the worker blocks on `queue.take()`, then drains everything else with `queue.poll()`; 3. the worker forwards the drained list in one `processBatch` call; 4. at `testEnded`, a sentinel event is queued to stop the worker cleanly. Note that `Asynch` is *also* a batching mode — the worker groups whatever it can drain — but it does **not** read `num_sample_threshold` or `time_threshold`. Its batch size is whatever the queue happened to hold. That is why the manual describes it as smoothing peaks in sample generation. ## When the queue fills The queue is bounded, so it can only absorb a burst; it cannot absorb a sustained excess. When the worker cannot forward events as fast as the samplers create them: - `queue.offer(e)` returns `false`; - the sender increments `queueWaits`, takes a `System.nanoTime()` reading, and calls `queue.put(e)`; - `put` blocks the **sampler thread** until the worker frees a slot; - the elapsed nanoseconds are added to `queueWaitTime`. The block happens in the listener notification that follows the sample, not during it, so the sample's own `elapsed` value is untouched. What is affected is the thread's next iteration: it starts later than it otherwise would. Naming that effect precisely matters — attributing an observed throughput shortfall to the generator rather than to the system under test is performance-testing fundamentals material, and this leaf only tells you where JMeter records the evidence. ## How you know it happened `AsynchSampleSender` logs twice, both into the engine's log file: - at start-up, the resolved capacity: `Using batch queue size (asynch.batch.queue.size): 100`; - at `testEnded`, and **only if `queueWaits > 0`**: `QueueWaits: 4821; QueueWaitTime: 913442000 (nanoseconds)`. Because the second line is conditional, its absence means no sampler thread ever waited. That is an unusually clean signal for a JMeter internal, and it is the reason `Asynch` is worth reaching for when you want the question answered rather than assumed. ## Sizing it, and what it does not fix | Symptom | Does Asynch help? | |---|---| | sampler threads stalling on the RMI call | yes — that is exactly the coupling it removes | | bursty sample generation, adequate average rate | yes — the queue absorbs the peak | | controller cannot keep up with the sample volume | no — every event still arrives | | engine short of heap | no, and a large queue makes it worse | `asynch.batch.queue.size`, like the batch thresholds, is read into an instance field on the controller and into a static field on the engine, with `sample_sender_client_configured` (default `true`) choosing between them at `readResolve`. So by default you size the engines' queues from the controller's properties file, despite the manual saying the property is set on the server node. `StrippedAsynch` is the same sender with a `DataStrippingSampleSender` in front of it, and is the variant to prefer if you do not need response bodies — smaller events drain faster, so the queue fills less often.