import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 200 },
    { duration: '8m', target: 200 },
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<1500', 'p(99)<3000'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/checkout');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Protocol Surface

JMeter wins this category outright. Out of the box plus the plugins ecosystem, JMeter handles HTTP, HTTPS, JDBC (Oracle, MySQL, Postgres, SQL Server), JMS, MQTT, AMQP, FTP, LDAP, SOAP, gRPC (via plugin), TCP, and SMTP. If you need to load-test an enterprise message bus or a legacy protocol, JMeter probably has a plugin for it.

k6 covers HTTP/1.1, HTTP/2, HTTP/3, WebSocket, gRPC, browser automation via xk6-browser (Chromium), and an extension model (xk6) that lets the community add protocols in Go. The xk6 ecosystem now includes Kafka, Redis, MQTT, SQL, and AMQP. The list is growing but is not yet at JMeter parity for niche enterprise protocols.

CI/CD Integration

k6's startup time is sub-second. The binary is 70 MB. Tests run inline in CI jobs without spinning up a JVM, fetching plugins, or persisting state. A k6 step is roughly the cost of any other shell-script step, which is why teams shipping multiple times per day adopt it for inline regression testing.

JMeter's startup time is 3-8 seconds for the JVM, plus plugin loading. The JMX format requires a checked-in test plan that travels with the source. CI workflows work but are heavier — pull the binary, fetch plugins, run, parse the JTL output. Plenty of teams do this successfully; it is just more friction than k6.

Reporting and Observability

Both tools produce solid reports, but they emphasise different things.

For teams running existing dashboards in end-to-end prometheus grafana, both tools land their metrics there cleanly. k6's Prometheus remote-write output and JMeter's InfluxDB Backend Listener both feed into the same Grafana panels you already use for production monitoring.

What About the Often-Overlooked Operational Costs?

Tooling selection is rarely just about features. Two operational dimensions get underweighted in tool reviews:

Generator infrastructure. JMeter's per-VU overhead means you pay more for compute. A 50,000 VU sustained test is 10-15 mid-sized JMeter generators on AWS or Azure spot pricing. The same test on k6 is one or two generators. Over a year of nightly runs, the difference is several thousand euros — small if performance testing is critical, meaningful if you are bootstrapping the practice and need to justify the spend.

Onboarding cost. A developer onboarded to k6 writes useful tests in a day. JMeter's GUI-driven authoring and JMX format takes longer for first-test productivity, particularly for engineers who don't already know the tool. For organisations where every developer is expected to add load tests for the services they own, the onboarding curve compounds across the team. For organisations with a dedicated performance-engineering team that owns the harness, the onboarding cost is paid once and amortised — and JMeter's protocol breadth often pays it back.

Decision Matrix

The Pragmatic Answer: Run Both

The two tools are not mutually exclusive. The most mature engineering organisations we work with run k6 for the 80% of HTTP / gRPC tests that live in the same repo as the service code, and JMeter for the long tail of legacy and non-HTTP workloads that QA owns separately. The two outputs land in the same observability backend, the same dashboards, and the same alerts. Engineers and QA leads see correlated results.

Forcing the team onto a single tool to "standardise" usually fails — k6 won't model your JMS broker, and JMeter is too heavy for inline PR regression tests. A polyglot harness is the realistic answer for organisations with both modern microservices and legacy systems in their portfolio. We see the same pattern in CI runner choice, where teams run a SaaS CI for cloud-native services and Jenkins for legacy on-prem builds, and we recommend the same approach for load testing in our Opsio's pipeline services engagements.

How Opsio Helps

Opsio's zero-downtime load testing implements whichever tool — or combination — fits the customer's actual stack. We design the harness, integrate it into pipelines, run the first baseline tests, and hand over a repeatable operating model. Customers leave with both tools running in parallel where it makes sense, and the engineering data to back the choice rather than tribal preference.