Przejdź do treści
Biblioteka skilli
DevOps i chmura · Testowanie

test-load

/test-load

Projektuje i uruchamia profil obciążenia w k6 lub Artillery, mierząc przepustowość, percentyle opóźnień, odsetek błędów i punkt załamania systemu.

Repozytorium
cursor-kenji ↗
Licencja
MIT
Ostatnia zmiana repozytorium
19.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 19.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Projektuje i uruchamia profil obciążenia w k6 lub Artillery, mierząc przepustowość, percentyle opóźnień, odsetek błędów i punkt załamania systemu.

Wyzwalacze z opisu

load test thiswill it handle launch trafficfind the breaking point
Oryginalny opis (EN)

Design and run a k6 or Artillery load profile: throughput, latency percentiles, error rate, breaking point. Use when "load test this", "will it handle launch traffic", or "find the breaking point". Code-level resilience → audit-resilience.

Jak działa

  1. This skill vs neighbors
  2. How to reason
  3. Worked example
  4. Phase 0 — Detect stack and set targets [HIGH freedom]
  5. Phase 1 — Model realistic load [HIGH freedom]
  6. Phase 2 — Graduated profiles [LOW freedom — smoke → load → stress → spike]
  7. Phase 3 — Measure the right things [HIGH freedom]
  8. Definition of Done
  9. Self-critique before reporting [LOW freedom — do not skip]
  10. Output format
Sekcje z nagłówków SKILL.md, w oryginale · 118 linii, 721 słów
Podgląd SKILL.md
---
name: test-load
description: >
  Design and run a k6 or Artillery load profile: throughput, latency
  percentiles, error rate, breaking point. Use when "load test this", "will it
  handle launch traffic", or "find the breaking point". Code-level resilience
  → audit-resilience.
license: MIT
---

# test-load — Measured concurrency, not a guess

**Degree of freedom: MIXED** — journey design `[HIGH freedom]`; env choice
and profile order `[LOW freedom]`. **Never production without explicit
sign-off and rate caps.**

Turn "I think it'll hold" into numbers: at N concurrent users, p95 is X, error
rate is Y, it falls over at Z.

**`audit-resilience` tells you retries exist; this proves whether they save you
when 500 people arrive at once.**

## This skill vs neighbors

| Skill | Owns |
|---|---|
| **test-load** (this) | Concurrent traffic profiles + measured SLO |
| `audit-resilience` | Timeouts/retries/idempotency *in code* |
| `audit-infra-cost` | Consumes these capacity numbers to right-size |
| `audit-performance` | Single-user Web Vitals / bundle |
| `backend-db-performance` | Query/index fixes after this names the bottleneck |
| `plan-llm-cost-guardrails` | Model-token spend, not HTTP concurrency |

Load against production only with explicit sign-off and rate caps — an uncapped run is a self-inflicted outage. Prefer prod-like staging.

## How to reason

1. **Observe** — profile, VUs, p95/p99, error types, host/DB metrics
2. **Interpret** — SLO miss vs capacity vs cascade (pool / limiter / memory)
3. **Classify** — pass / degrade / breaking-point / invalid (unsigned prod)
4. **Severity** — named failing resource + whether failure is graceful

## Worked example

> **Observe:** load profile 200 VU, p95 2.4s (SLO 500ms), 8% 529s; DB
> `remaining connections = 0`.
> **Interpret:** pool exhaustion, not the Node process.
> **Classify:** SLO fail; breaking resource = DB pool.
> **Handoff:** `backend-db-performance` (pool + queries); numbers → `audit-infra-cost`.

---

## Phase 0 — Detect stack and set targets  [HIGH freedom]

- Tool: **k6** preferred (scriptable, CI-friendly); Artillery as fallback
- Target env + auth method
- **Goal first** (without it the test is noise):
  - Expected peak concurrency (ads / launch)
  - Acceptable p95/p99 and max error rate (SLO)
  - Capacity (hold at peak) vs breaking point (where it fails)

---

## Phase 1 — Model realistic load  [HIGH freedom]

- **Journeys, not one URL** — signup → browse → action, with think-time
- **Mix** — weight by real traffic (mostly reads)
- **Data variety** — pool of users/inputs, not one cached row
- **Auth** — real login or pre-provisioned tokens (unauthenticated misses RLS cost)

---

## Phase 2 — Graduated profiles  [LOW freedom — smoke → load → stress → spike]

1. **Smoke** — few VUs; script + baseline healthy
2. **Load** — ramp to expected peak, soak several minutes (SLO pass/fail)
3. **Stress** — past peak until degrade; name the failing resource
4. **Spike** — instant jump (viral ad); does it recover?
5. Optional **soak** — 30+ min for leaks / pool exhaustion

---

## Phase 3 — Measure the right things  [HIGH freedom]

- Latency **percentiles** (p50/p95/p99) — averages hide pain
- Error rate **and types** (timeout vs 5xx vs refused)
- Throughput (req/s) per level
- Bottleneck: DB pool, function concurrency, rate limiter, memory, cold start
- Correlate Supabase / Sentry / host metrics during the run

Keep the reusable script in the repo as a reviewable change (commit only when asked). Hand capacity numbers to `audit-infra-cost`.

---

## Definition of Done

- [ ] Tool + env chosen; prod excluded or signed + capped
- [ ] SLO stated before running
- [ ] Journeys weighted, think-time, varied data, real auth
- [ ] Smoke → load → stress → spike run
- [ ] Percentiles, errors, throughput captured
- [ ] Breaking point + failing resource named
- [ ] SLO verdict + fix handoff
- [ ] Script in the repo, ready to commit

## Self-critique before reporting  [LOW freedom — do not skip]

1. **SLO stated first** — a run without a target is noise
2. **Not unsigned prod** — if only prod exists, stop
3. **Percentiles, not averages**
4. **Breaking resource named** — not "it got slow"
5. **Journeys, not one URL**

## Output format

1. **Design** — SLO, journeys, env, profiles
2. **Results** — profile | VUs | throughput | p50/p95/p99 | errors | vs SLO
3. **Breaking point** — where, why, graceful vs cascade
4. **Handoff** — `backend-db-performance`, `backend-patterns`, `audit-resilience`, `audit-infra-cost`

## Related

- `audit-resilience` — code-level NFRs
- `audit-infra-cost` — right-size from these numbers
- `backend-db-performance` / `backend-patterns` — fix the named bottleneck
- `audit-performance` — single-user frontend

Wersje

W bazie nie ma innych skilli o nazwie test-load.

Migawka bazy z 13.11.2026 · wersja paczki 25450003cbb3 (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 90load-testing
    Testuje system realistycznym ruchem, by znaleźć punkt załamania przed użytkownikami, mierząc percentyle opóźnień i błędy razem.
  • 100load-test
    Przygotowuje, uruchamia i analizuje testy obciążeniowe w k6, Artillery lub Locust: skrypty, scenariusze narastania VU, interpretacja opóźnień p99 i błędów oraz wskazówki naprawy infrastruktury.
  • 100http-load-testing
    Wykonuje testy obciążeniowe HTTP w narzędziu oha: mierzy percentyle opóźnień, znajduje punkt załamania serwera i sprawdza cele SLA z korektą coordinated omission.
  • 100testing-performance-and-load
    Projektuje i uruchamia testy wydajności i obciążenia: modelowanie ruchu z realnych danych, progi powiązane z SLO, analiza percentyli i lekkie kontrole w CI z k6 lub Artillery.
  • 100performance-testing
    Prowadzi testy obciążeniowe systemu: model obciążenia, profile narastania, co mierzyć, szukanie punktu załamania i odróżnianie prawdziwego wąskiego gardła od źle skonfigurowanego testu.
  • 100running-load-tests
    Tworzy i uruchamia testy obciążeniowe w k6, JMeter i Artillery, aby sprawdzić wydajność aplikacji pod obciążeniem i znaleźć wąskie gardła.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.