Load testing
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill load-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Simulate realistic multi-user load with ramp profiles, think time, and pacing, then find where the system saturates. Use when validating capacity or headroom for a service before a launch or expected traffic spike.
SKILL.md
3.0 KB, as published. Nobody here has run it
Load testing
A load test that fires requests as fast as a loop allows measures your load generator, not your users. Real traffic arrives in waves, with pauses between actions and a mix of endpoints, from clients spread across a network. Model that shape honestly or you will size the system for a workload that never happens and be surprised by the one that does.
Method
- Model the scenario from real traffic. Pull endpoint mix, request ratios, and payload sizes from production logs or access metrics. A test that hammers one cheap endpoint proves nothing about a homepage that fans out to eight services.
- Add think time between steps. Insert realistic pauses, one to several seconds, between a user's actions. Zero think time concentrates load into an unnatural burst and inflates contention that real users never create. In k6, Locust, or Gatling this is an explicit sleep or pace setting.
- Ramp, do not slam. Start at low concurrency and increase virtual users in stages, holding each level long enough to reach steady state. A step ramp shows how latency responds to load; a cold jump to full concurrency only shows connection-storm behavior.
- Run the generator off the system under test. Drive load from separate machines close in the network to the target. A generator sharing CPU with the service competes with it and corrupts every number you collect.
- Watch for the saturation knee. As you add users, throughput rises then flattens while latency climbs: that inflection is the capacity limit. Report the concurrency at the knee, not the maximum requests you managed to push through it.
- Assert on percentiles and error rate, not the mean. Gate on p95 and p99 latency and the failure rate against the service level objective. An average of 80ms can hide a p99 of four seconds and a rising stream of 500s.
- Push to failure once, on purpose. In an isolated environment, ramp past the knee until the system breaks and record how: queue overflow, timeouts, out-of-memory. Knowing the ceiling and the failure mode is worth more than a clean pass.
Signals
- Does the load profile reproduce production's endpoint mix and pacing, or just one hot loop?
- Can you name the concurrency level where latency crossed the objective and the mode the system failed in beyond it?
- Are your reported numbers percentiles under sustained steady-state load, not averages from the ramp?
Boundaries
Load testing sizes a system under concurrent traffic; single-function timing belongs to performance-testing. It measures behavior under load, not behavior under failure: deliberately killing instances or injecting latency is chaos-testing. Capacity targets and cost ceilings are product and budget decisions this test informs but does not set.