Queue and worker load testing
Measures whether asynchronous work can absorb bursts and recover from downstream failure without runaway retries or duplicated effects.
queue-worker-load-testing
Team members using this skill
When is it useful?
Use it when queue depth grows, jobs age unexpectedly or increasing worker count fails to improve completion time.
What does it help you do?
- Measures arrival, completion, backlog and oldest-job age separately.
- Tests burst drain time against database and provider bottlenecks.
- Exercises lease expiry, poison messages and retry amplification.
Try asking this
Measure how long an email queue recovers after a bounded provider outage. Block the test mail provider briefly, restore it and track oldest-job age. Confirm the backlog drains without duplicate mail or exhausted retry capacity.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Queue & Worker Load Testing
When to Use
Use when load testing background job processors, event-driven pipelines, webhook consumers, media/document workers, or scheduled batch workflows (BullMQ/Redis, RabbitMQ, SQS, Kafka, Celery, Laravel Horizon/Queue, Sidekiq, Postgres/SQLite job tables).
Queueing Fundamentals & Core Metrics
HTTP response time (202 Accepted) only measures how fast a job was enqueued—it says nothing about whether workers can keep up! Always measure the complete asynchronous lifecycle:
1. The Four Essential Queue Metrics
- Enqueue / Arrival Rate ($\lambda_{\text{in}}$): Jobs or messages added per second.
- Completion / Drain Rate ($\mu_{\text{out}}$): Jobs successfully processed per second.
- Queue Depth / Backlog ($L_q$): Number of waiting + active jobs. Whenever $\lambda_{\text{in}} > \mu_{\text{out}}$ for duration $T$, backlog grows at $(\lambda_{\text{in}} - \mu_{\text{out}}) \times T$.
- Oldest Unprocessed Job Age / End-to-End Queue Latency ($W_{\text{total}} = t_{\text{completed}} - t_{\text{enqueued}}$): The true user-facing SLI. Even a small backlog causes huge latency if workers stall on slow jobs.
2. Backlog Build-Up & Drain-Time Verification
Test both steady-state sustainability ($\lambda_{\text{in}} \le \mu_{\text{out}}$) and burst drain recovery:
- Inject a realistic burst batch (e.g., $5,000$ jobs at $\lambda_{\text{in}} = 250\text{/s}$ while workers process at $\mu_{\text{out}} = 50\text{/s}$).
- Measure:
- Peak queue depth and memory footprint in the broker (Redis
used_memory, SQS/RabbitMQ ready messages, DB queue table lock contention). - Drain Time ($T_{\text{drain}}$): Time required to bring queue depth back to
0once burst ingestion stops. - Head-of-line blocking: Do slow/heavy jobs starve fast, latency-sensitive jobs (e.g., password reset emails stuck behind bulk PDF exports) because they share a single queue or worker pool?
- Peak queue depth and memory footprint in the broker (Redis
3. Concurrency, Lock Contention & Visibility Timeouts
- Tune worker concurrency against downstream bottlenecks: increasing worker threads from
10to100often reduces throughput if all 100 workers contend for a 20-connection database pool or hit third-party API rate limits. - Verify Lease / Visibility Timeout / Lock Renewal (
lockDuration/stalledInterval):- When a job takes longer under high load (e.g.,
45svs normal5s), check whether its lock expires prematurely, causing another worker to pick up the same job concurrently.
- When a job takes longer under high load (e.g.,
- Assert Idempotency & At-Least-Once Correctness:
- Verify that duplicate deliveries or stalled-job retries do not produce duplicate side effects (double billing, duplicate notifications, corrupted state).
4. Poison Messages, Retry Storms & Dead-Letter Queues (DLQ)
- Inject controlled downstream failures (e.g.,
10%upstream503or malformed payloads) during load:- Confirm retries use exponential backoff with jitter, not immediate tight-loop retries that multiply queue load (
retry amplification). - Confirm permanently failing jobs transition to the Dead-Letter Queue (
failed/DLQ) aftermaxAttemptswithout blocking healthy jobs.
- Confirm retries use exponential backoff with jitter, not immediate tight-loop retries that multiply queue load (
Included files 1
SKILL.md
