Feladatsor és worker terhelése
Méri, elviseli-e az aszinkron munka a terhelési hullámot és szolgáltatáskiesést elszabaduló próbálkozás vagy dupla hatás nélkül.
queue-worker-load-testing
Ezt a skillt használó csapattagok
Mikor hasznos?
Akkor használd, ha nő a sor, öregszenek a feladatok vagy több worker sem javítja a teljesítést.
Miben segít neked?
- Külön méri a beérkezést, teljesítést, torlódást és legrégebbi feladat korát.
- Adatbázis- és szolgáltatói korlát mellett teszteli a kiürülési időt.
- Vizsgálja a foglaláslejáratot, hibás üzenetet és újrapróbálási sokszorozódást.
Például ezt kérheted
Mérd meg a levélküldési sor helyreállását korlátozott szolgáltatáskiesés után. Röviden blokkold a tesztlevél-szolgáltatót, majd állítsd helyre és mérj feladatkort. A sor duplikált levél és kimerülő újrapróbálás nélkül fogyjon el.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
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 (
Csomagban lévő fájlok 1
SKILL.md
