AgentStack
SKILL verified Apache-2.0 Self-run

Api Load Tester

skill-terminalskills-skills-api-load-tester · by TerminalSkills

>-

No reviews yet
0 installs
19 views
0.0% view→install

Install

$ agentstack add skill-terminalskills-skills-api-load-tester

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access Used
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Api Load Tester? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

API Load Tester

Overview

This skill generates realistic load test scripts from API definitions and executes them with proper ramp-up patterns, authentication flows, and assertions. It produces clear reports identifying breaking points, bottlenecks, and latency percentiles at each traffic level.

Instructions

Step 1: Choose Tool and Gather API Info

Prefer k6 for complex scenarios (multi-step flows, thresholds, custom metrics). Use wrk for quick single-endpoint benchmarks. Use autocannon if only Node.js is available.

Gather endpoint information from:

  • OpenAPI/Swagger spec files
  • Route definitions (Express, FastAPI, etc.)
  • User-described endpoints

Step 2: Generate Realistic Payloads

Read request/response types from the codebase (TypeScript interfaces, Python dataclasses, Go structs) and generate payloads with:

  • Realistic field values (not "test123" or "foo")
  • Proper data distributions (varied product IDs, realistic quantities)
  • Edge cases mixed in (long strings, special characters at ~5% rate)

Step 3: Design Test Scenarios

Create scenarios appropriate for the goal:

Ramp-up test (finding breaking point):

stages: [
  { duration: '2m', target: 50 },    // warm-up
  { duration: '5m', target: 200 },   // ramp
  { duration: '3m', target: 500 },   // push
  { duration: '2m', target: 500 },   // sustain
  { duration: '2m', target: 0 },     // cool-down
]

Soak test (finding memory leaks, connection exhaustion):

stages: [
  { duration: '5m', target: 100 },   // ramp
  { duration: '60m', target: 100 },  // sustain
  { duration: '5m', target: 0 },     // cool-down
]

Spike test (sudden traffic burst):

stages: [
  { duration: '2m', target: 50 },    // normal
  { duration: '30s', target: 500 },  // spike
  { duration: '5m', target: 500 },   // sustain spike
  { duration: '30s', target: 50 },   // drop back
]

Step 4: Include Proper Assertions

Always add thresholds:

thresholds: {
  http_req_duration: ['p(95) r.status === 200 });
}
EOF
Results — /api/search @ 100 VUs for 60s
  Requests:    8,423 total (140.4 RPS)
  Latency:     p50=89ms  p95=340ms  p99=890ms
  Errors:      12 (0.14%)
  Data:        24.3 MB received

Verdict: Endpoint handles 140 RPS at 100 VUs. p99 approaching 1s suggests
database query optimization needed for sustained higher load.

Example 2: Multi-Step Flow

User prompt:

Create a load test for our signup → login → create-project flow

Agent generates a k6 script with:

  • Step 1: POST /api/auth/signup with randomized email/name
  • Step 2: POST /api/auth/login to get JWT
  • Step 3: POST /api/projects with auth header and realistic project data
  • Custom metrics tracking each step's latency separately
  • Sleep between steps to simulate real user behavior

Guidelines

  • Never load test production without explicit confirmation — always clarify the target environment
  • Start low, ramp gradually — sudden jumps make it hard to identify the exact breaking point
  • Realistic think time — add sleep(1-3) between requests to simulate real users; without it, you're testing throughput, not user concurrency
  • Authentication matters — many bottlenecks only appear with real auth flows (token validation, session lookups)
  • Watch for connection reuse — k6 reuses connections by default, which is realistic for browsers but not for serverless/mobile clients
  • Rate limit awareness — if the API has rate limiting, note it in the report; it's not a performance bottleneck, it's intentional
  • Report infrastructure context — always note the server specs, pod count, and database size alongside results

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.