load-testing
Deep load testing workflow—goals and SLOs, workload modeling, scenario design, environment fidelity, execution, metrics interpretation, and bottlenecks to fixes. Use when validating capacity, before launches, or reproducing latency under stress.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/codenova58/load-testingLoad Testing (Deep Workflow)
Load tests answer whether the system meets behavior under target load—not “how many RPS the tool prints.” Tie every run to SLOs, workload realism, and analysis that engineers can act on.
When to Offer This Workflow
Trigger conditions:
- Major launch, traffic spike season, infra resize
- Latency/timeout under peak; need evidence for capacity decisions
- Comparing architectures or debottlenecking
Initial offer:
Use seven stages: (1) goals & SLOs, (2) workload model, (3) scenarios & scripts, (4) environment & data, (5) run & observe, (6) analyze bottlenecks, (7) fixes & retest. Confirm tool (k6, Locust, Gatling, JMeter) and environment policy (prod-like staging vs synthetic).
Stage 1: Goals & SLOs
Goal: Define success in measurable terms.
Questions
- Peak RPS/users, growth assumption, duration of peak
- SLOs: p95/p99 latency, error rate, throughput per critical endpoint
- Scope: read-heavy vs write-heavy; background jobs interaction
Exit condition: Numeric targets + out of scope (e.g., “third-party API mocked”).
Stage 2: Workload Model
Goal: Representative mix—not one URL forever.
Practices
- Transaction mix from analytics or access logs (proportions)
- Think time between steps for user journeys
- Payload size distribution; auth token behavior
- Spike vs soak vs step ramp—match real failure modes
Exit condition: Workload profile documented (table or script comments).
Stage 3: Scenarios & Scripts
Goal: Deterministic, idempotent load scripts where possible.
Practices
- Correlate virtual user with trace/request id for debugging
- Parameterize data to avoid cache fantasy (every request hits same key)
- Order operations to match real causality (login → browse → checkout)
Pitfalls
- Client-side bottleneck (single generator machine)—distribute load generators
Exit condition: Smoke run at small k validates script correctness.
Stage 4: Environment & Data
Goal: Fidelity without destroying prod.
Rules
- Staging scale proportional; feature flags aligned
- Data volume similar order-of-magnitude for DB plans
- External deps: mock, sandbox, or throttle awareness
Exit condition: Safety checklist: no prod writes unless explicitly planned and isolated.
Stage 5: Run & Observe
Goal: System-wide visibility during test.
Instrumentation
- App: latency histograms, error codes, queue depth
- Infra: CPU, memory, connections, GC, disk IOPS
- DB: slow queries, locks, replication lag
- Tracing sample during test for hot spans
Exit condition: Dashboard or runbook link for the test window.
Stage 6: Analyze Bottlenecks
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-codenova58-load-testing": {
"enabled": true,
"auto_update": true
}
}
}