---
title: "Comment by Daniel Collins on \"k6 vs JMeter: The Same 100-User Load Test, Side by Side\" | Hashnode"
description: "The detail that stood out to me was the request count — 3,000 from k6 against 2,874 from JMeter. With a 1-second ramp-up on the JMeter side, that gap is more li"
url: "https://hashnode.com/posts/k6-vs-jmeter-the-same-100-user-load-test-side-by-side/6af61ddbbff92477066dc65e/comment/6af6b0512b691df1c0fc06d1"
---

[Discussion](https://hashnode.com/posts/k6-vs-jmeter-the-same-100-user-load-test-side-by-side/6af61ddbbff92477066dc65e)

Comment [k6 vs JMeter: The Same 100-User Load Test, Side by Side](https://hashnode.com/posts/k6-vs-jmeter-the-same-100-user-load-test-side-by-side/6af61ddbbff92477066dc65e)

[Daniel Collins](https://hashnode.com/@fabbalancecheckuae)

[2d ago](https://hashnode.com/posts/k6-vs-jmeter-the-same-100-user-load-test-side-by-side/6af61ddbbff92477066dc65e/comment/6af6b0512b691df1c0fc06d1)

The detail that stood out to me was the request count — 3,000 from k6 against 2,874 from JMeter. With a 1-second ramp-up on the JMeter side, that gap is more likely timing than tool performance, which makes the near-identical response times the more honest headline here.

I also liked that the k6 typo fails loudly with exit code 104. A test that silently ignored a broken threshold would be far worse in CI than one that refuses to run. That is a good argument for keeping thresholds in version control and reviewing them like code, rather than treating them as a setting you tweak in a GUI and forget.

For a next run, I would be curious to see the same test with a gradual ramp and a less trivial endpoint, so the tools are stressed on connection handling rather than just returning a tiny JSON payload.

[Rishabh Mishra](https://hashnode.com/@rushdeploy)

[2d ago](https://hashnode.com/posts/k6-vs-jmeter-the-same-100-user-load-test-side-by-side/6af61ddbbff92477066dc65e/comment/6af6b0512b691df1c0fc06d1#reply-6af6d117e4ebcb8a15dd97f1)

Good catch on the ramp — that 126-request gap is almost certainly timing, not the tools, so the matching response times are the real takeaway. For the next run I'd keep the ramp identical on both sides and use a DB-backed endpoint, so connection handling gets stressed instead of a tiny JSON payload. And you're right about exit code 104 — a test that fails loudly in CI beats one that silently passes with a broken threshold.