For the wider field including hosted options, see 10 best API load testing tools.

k6 vs JMeter vs Gatling compared

The same scenario in all three

Fifty virtual users, two minutes, p99 under 500 ms and an error rate under 1%.

k6 — the whole thing including pass/fail:

// load.js  —  k6 run load.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 50,
  duration: '2m',
  thresholds: {
    http_req_duration: ['p(99)<500'],   // the budget, enforced
    http_req_failed: ['rate<0.01'],
    checks: ['rate>0.99'],
  },
};

export default function () {
  const res = http.get(`${__ENV.BASE_URL}/v1/orders`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
  });
  check(res, {
    'status is 200': (r) => r.status === 200,
    'body has items': (r) => r.json('items') !== undefined,
  });
  sleep(1);
}

If a threshold is missed, k6 run exits non-zero. That single fact is why k6 ends up in pipelines.

Gatling — the same scenario, with assertions in the simulation:

// src/test/java/OrdersSimulation.java
import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;
import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

public class OrdersSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol = http
      .baseUrl(System.getenv("BASE_URL"))
      .authorizationHeader("Bearer " + System.getenv("TOKEN"))
      .acceptHeader("application/json");

  ScenarioBuilder orders = scenario("List orders")
      .exec(http("GET /v1/orders").get("/v1/orders").check(status().is(200)))
      .pause(1);

  {
    setUp(orders.injectOpen(rampUsers(50).during(30)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(99).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

JMeter — the test plan is XML, so the honest way to show it is the CLI invocation plus the assertion you configure in the plan:

# non-GUI mode is the only mode you should use for a real run
jmeter -n -t orders.jmx \
  -Jusers=50 -Jduration=120 -JbaseUrl="$BASE_URL" \
  -l results.jtl \
  -e -o report/

fail the build from the results file, since JMeter will not do it for you

python - <<'PY' import csv, sys rows = list(csv.DictReader(open("results.jtl"))) elapsed = sorted(int(r["elapsed"]) for r in rows) p99 = elapsed[int(len(elapsed) * 0.99) - 1] errors = sum(1 for r in rows if r["success"] != "true") / len(rows) print(f"p99={p99}ms error_rate={errors:.3%}") sys.exit(0 if p99 < 500 and errors < 0.01 else 1) PY

That last block is the difference in a nutshell. k6 and Gatling both express the budget inside the test; with JMeter you either add a plugin or write the gate yourself.

## Putting a performance budget in the pipeline

```yaml
# .github/workflows/perf.yml
name: Performance budget
on:
  pull_request:
    paths: ['src/**', 'openapi.yaml']
  schedule: [{ cron: '0 3 * * *' }]     # the long run, off the critical path
jobs:
  smoke-load:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install k6
        run: |
          curl -sL https://github.com/grafana/k6/releases/latest/download/k6-v0.50.0-linux-amd64.tar.gz \
            | tar xz --strip-components=1 -C /usr/local/bin '*/k6'
      - name: 2-minute load with thresholds
        run: k6 run load.js
        env:
          BASE_URL: ${{ vars.STAGING_URL }}
          TOKEN: ${{ secrets.API_TOKEN }}
      - name: Full soak (nightly only)
        if: github.event_name == 'schedule'
        run: k6 run --vus 200 --duration 30m soak.js

The pattern that works: a short thresholded run on every pull request so a regression is caught while the change is still small, and the long soak, stress and spike runs on a schedule where they do not block anyone.

How to choose

• k6 if you want performance testing in CI with the least friction, your team writes JavaScript, and HTTP, WebSocket and gRPC cover your protocols.
• JMeter if you need a protocol its plugins already cover (JDBC, JMS, MQTT, LDAP, FTP), if the team's existing assets are .jmx, or if a GUI builder genuinely lowers the barrier for the people who will run it.
• Gatling if you are on the JVM, want the best report and the most efficient load generation, and are comfortable maintaining a real DSL.

One thing none of them does: tell you which endpoints to load test. That comes from traffic data and from the contract — the operations that carry the most requests and the ones with the tightest SLOs. See how to test API rate limiting for the throttling half of the same question.

Distributed load and where each one breaks

A single load generator saturates long before most production APIs do, so the distributed story matters as soon as you are testing anything real.

The common mistake is treating a load-generator limit as an application limit. Before believing any result, check that the generator was not the bottleneck:

# if CPU on the generator is pegged, the numbers describe your laptop
k6 run --vus 200 --duration 5m load.js &
pidstat -u -p $(pgrep -f 'k6 run') 5

Rule of thumb: if generator CPU is above about 70%, add generators before drawing conclusions. JMeter reaches that point far sooner than the other two because of its thread-per-user model, which is the main practical reason large runs migrate away from it.

Choosing what to load test

All three tools answer "how does this endpoint behave under load". None answers "which endpoints matter", and picking wrong is the most common way a load-testing programme produces reassuring numbers about traffic nobody sends.

Derive the list from two sources:

# 1. what actually gets traffic — the top ten by request rate
topk(10, sum by (route) (rate(http_requests_total[7d])))

# 2. what is already closest to its budget — the tail latency offenders
topk(10, histogram_quantile(0.99,
  sum by (route, le) (rate(http_request_duration_seconds_bucket[7d]))))

Then weight the scenario to match reality rather than testing each endpoint in isolation:

// load.js — traffic mix, not a uniform hammer
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    browse:   { executor: 'constant-arrival-rate', rate: 80, timeUnit: '1s',
                duration: '5m', preAllocatedVUs: 100, exec: 'browse' },
    checkout: { executor: 'constant-arrival-rate', rate: 5, timeUnit: '1s',
                duration: '5m', preAllocatedVUs: 30, exec: 'checkout' },
  },
  thresholds: {
    'http_req_duration{scenario:browse}': ['p(99)<300'],
    'http_req_duration{scenario:checkout}': ['p(99)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browse() {
  check(http.get(`${__ENV.BASE_URL}/v1/catalog`), { ok: (r) => r.status === 200 });
}
export function checkout() {
  check(http.post(`${__ENV.BASE_URL}/v1/orders`, JSON.stringify({ sku: 'A-1', qty: 1 }),
    { headers: { 'Content-Type': 'application/json' } }), { ok: (r) => r.status === 201 });
}

Separate thresholds per scenario is the detail worth copying: a checkout that takes 800 ms is fine, and a catalogue listing that takes 800 ms is a regression. One global threshold hides both.

Sources and further reading

• Grafana k6 documentation — scripting, thresholds and output backends.
• Apache JMeter User Manual — test plans, non-GUI mode and the HTML dashboard.
• Google SRE Workbook — Implementing SLOs — where the number in your threshold should come from.

Key takeaways

• k6 is the lowest-friction option for CI: one binary, JavaScript scripts in the repository, and thresholds that make the process exit non-zero.
• Gatling is the most efficient per load generator and has the best out-of-the-box report, at the cost of a real DSL to learn.
• JMeter remains the answer for non-HTTP protocols and for teams with existing .jmx assets, but its XML test plans review badly and it will not fail your build without extra work.
• Express the budget inside the test where the tool supports it — a load test with no pass/fail is a report nobody reads.
• Short thresholded run on every pull request, long soak on a schedule: that split keeps performance testing useful without slowing delivery.

Related articles

10 Best API Load Testing Tools | k6 Load Testing Tutorial | JMeter API Testing Tutorial | How to Test API Rate Limiting | Monitoring API Performance in Production