A load test is traffic you are deliberately sending at a host. Run it against staging, or against production only with written approval from whoever owns the service and the infrastructure bill. Shared hosting, managed API gateways, and third-party endpoints usually forbid it outright in their terms.
Most teams do not stall on writing k6 syntax. They stall on the first ten minutes: which stages to declare, where the token goes, what counts as a failed run. This page turns those decisions into fields and hands back a file that already has the shape.
What comes out is a starting point with your numbers baked in, not a tuned benchmark. Endpoints, credentials, and pacing still need your judgment. The sections below say exactly which parts are yours to finish.
How each field lands in the file
- Virtual users and ramp-up
k6 gets a three-stage array: ramp to your user count over the ramp-up seconds, hold for the duration, then a fixed 30 second ramp-down. JMeter sets
num_threadsandramp_timewith the scheduler on. Locust prints the matchinglocust -u -r -tcommand in a trailing comment. - Duration
Entered in minutes, written in the unit each tool expects:
10mfor k6,600seconds for JMeter and Artillery,10.minutesfor Gatling. - Think time
A
sleep()at the end of the k6 iteration, a JMeter ConstantTimer in milliseconds, a Gatling.pause(), and a Locustbetween(t, t+1)window. - Thresholds
Only written when the threshold assertions box stays ticked. p95 latency becomes
http_req_duration: ['p(95)<500']in k6, anensureblock in Artillery, and aglobal.responseTime.p95assertion in Gatling. Error rate is divided by 100 for the tools that expect a fraction. - Headers
Each
Name: valueline becomes a header entry: a params object in k6, a HeaderManager in JMeter,defaults.headersin Artillery, chained.header()calls in Gatling, a dict in Locust. - Body
The body field appears only for POST, PUT, and PATCH, and is written verbatim. Invalid JSON goes through untouched, so the failure shows up when the tool parses it, not here.
The test type selector is a label, not a profile
This is the part worth knowing before you trust the output. Picking Spike or Endurance renames the scenario, the Gatling class, the Locust user class, and the k6 tag. The stages stay identical: ramp, hold, drop.
A real spike test needs a short violent step, for example 5 users for two minutes, then 500 for thirty seconds, then back down. An endurance test needs hours at a modest level with memory watched between runs. Both mean editing the stages block yourself after export. Treat the selector as documentation of intent for whoever opens the file next.
What each export assumes
k6
load-test.js
Closest to complete. Custom errorRate Rate metric, checks on status and duration, full URL used as written. Run with k6 run load-test.js.
JMeter
load-test.jmx
Opens in the GUI. Host and path are split out of your URL with __regexReplace functions and the protocol is hardcoded to https. Check both values in the sampler before a real run.
Artillery
load-test.yml
Phases use arrival rate, not concurrency. Your user count is divided by 60 to guess arrivals per second, which is a rough translation. Set it against your own numbers.
Gatling
load-test.scala
Drop it in src/test/scala. Mixes rampUsers during ramp-up with constantUsersPerSec for the hold, so arrivals continue after the ramp finishes.
Locust
load-test.py
Single HttpUser class with one task, plus a 404 probe task when error handling stays on. Path is taken from the URL and the host is set on the class.
Gaps you fill in by hand
- The login step posts
test@toolexe.comandpassword123to/loginand reads atokenfield. Swap all four values for your auth route and payload shape. - Artillery, Gatling, and Locust point at the path from your URL, so a base URL with no path produces a request to
/. Give the full endpoint path in the field. - Data-driven mode inlines three sample rows for k6 and Locust, and references a
test-data.csvyou have to create for Artillery and Gatling. - Nothing here writes a results dashboard, a CI job, or a baseline comparison. Wire the output into your own pipeline.
- One endpoint per file. Real user journeys with several steps need a second scenario written by hand, or a different starting point.
Reading a first result without fooling yourself
Run a five user warm-up before the real profile. If p95 is already over your threshold at five users, the load profile is not the problem and a bigger run tells you nothing new.
Watch the error rate and latency together. Latency that stays flat while errors climb usually means something upstream started rejecting fast, which is a queue or a rate limiter, not a slow database. The reverse, latency climbing with errors near zero, points at saturation you have not hit the limit of yet.
Also check the machine generating load. A laptop on hotel wifi caps out long before a well provisioned API does, and the graph looks the same either way.
Nearby tools
For micro-benchmarks of a function or query rather than an HTTP endpoint, the Performance Test Generator stays closer to code level. Slow SQL under load belongs on the Database Query Profiler.
If you need correctness coverage on the same endpoint first, start with the API Test Generator, then bring the working request here.
Generation runs in your browser. Target URLs, headers, and request bodies are never sent to Toolexe servers, and no traffic is generated from this page.
