Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

What Are 4 Open Source Performance Testing Tools?

A single runnable k6 load test script that ramps virtual users against a checkout endpoint and fails the build via p95 latency and error-rate thresholds, matching the walkthrough in the open source performance testing tools comparison.

Companion code for the Autonoma blog post: What Are 4 Open Source Performance Testing Tools?

Requirements

k6 only. There is no npm install and no node_modules here: k6 scripts run inside k6's own JavaScript runtime, not Node.

On macOS:

brew install k6

Linux and Windows install paths are covered in k6's installation docs.

Quickstart

git clone https://github.com/Autonoma-Tools/open-source-performance-testing-tools.git
cd open-source-performance-testing-tools
k6 run checkout-load-test.js

The test ramps to 50 virtual users over 30 seconds, then to 200 over the next minute, then back to 0 over a final 30 seconds. Total run time is about two minutes.

Pointing it at your own environment

The script reads BASE_URL from the environment and falls back to https://test.k6.io (k6's public demo site) when it is not set. To run it against your own staging or production environment:

BASE_URL=https://staging.example.com k6 run checkout-load-test.js

The bundled example script wraps that same call:

./examples/run-against-your-own-endpoint.sh https://staging.example.com

Reading the output

k6 prints a summary when the run finishes. The lines that matter:

  • vus: the number of active virtual users at a given moment. Use it to confirm the ramp actually reached 200 rather than stalling early because of a connection limit upstream.
  • iterations: how many times a virtual user completed the whole default function. This is your throughput figure. Divide by the run duration for a rough requests-per-second number for the full flow.
  • http_req_duration: total time per request, broken down by k6 into sending, waiting, and receiving. The percentile breakdown is the useful part. p(95) is the response time that 95% of requests beat and 5% did not. Averages hide the tail, p(95) does not.
  • http_req_failed: the share of requests that did not come back with a successful status.
  • The threshold verdict: a checkmark or an X next to each threshold at the bottom of the summary. This is the pass or fail signal.

Thresholds and CI

Two thresholds are defined in the script's options block:

Threshold Meaning Fails when
http_req_duration: ['p(95)<500'] 95th percentile response time p(95) crosses 500ms
http_req_failed: ['rate<0.01'] request error rate more than 1% of requests fail

When either threshold is breached, k6 exits non-zero. That is what makes this file usable as a build-gating step: drop k6 run checkout-load-test.js into a CI job and a performance regression fails the build the same way a failing lint rule would. No separate test runner and no extra reporting step required.

Project structure

.
├── checkout-load-test.js
├── examples/
│   └── run-against-your-own-endpoint.sh
├── LICENSE
└── README.md
  • checkout-load-test.js: the load test itself, including the staged ramp and both thresholds.
  • examples/: runnable examples you can execute as-is.

About

This repository is maintained by Autonoma as reference material for the linked blog post. Autonoma builds autonomous AI agents that plan, execute, and maintain end-to-end tests directly from your codebase.

If something here is wrong, out of date, or unclear, please open an issue.

License

Released under the MIT License, copyright 2026 Autonoma Labs.

About

Companion code for What Are 4 Open Source Performance Testing Tools?

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages