4 ms·

I just found out about k6, and I'm wondering why it's better than jmeter?

by robbyt 6y ago

imiric 6y ago
You might get a less biased response from someone else, and I don't have much experience with JMeter, but: - k6 prioritizes modern developer experience. Tests are written in JavaScript, run from the CLI and can be committed to the same repository along with unit and integration tests. As such it blurs the line between responsibilities of a traditional QA team and pushes for load/performance/stress testing to be done by application developers themselves. This enables developers to easily integrate k6 in their existing CI pipelines and run load tests early on in the development cycle rather than as an afterthought. - k6 is written in Go, so it's much easier to deploy and use as a static binary, which also brings considerable performance benefits over JMeter. You can see a detailed breakdown and comparison in this article[1], written by another commenter here and one of the original k6 authors: rlonn. :) OTOH JMeter is a much more mature tool and has many more integrations and protocol support than k6. We recently launched an extension system for k6[2] that allows developers to add support for other protocols or features via native Go libraries, but the ecosystem is still in its infancy. So if you don't mind the JMeter UX, its performance or need some of its features, by all means stick with JMeter. But I would encourage you to give k6 a try for yourself, as it was written precisely out of the same frustrations mentioned in the article. [1]: https://k6.io/blog/comparing-best-open-source-load-testing-tools https://k6.io/blog/comparing-best-open-source-load-testing-t... [2]: https://k6.io/blog/extending-k6-with-xk6 https://k6.io/blog/extending-k6-with-xk6
liveoneggs 6y ago
it's easier to kick off in a jenkins pipeline since it's standalone but is otherwise less powerful, less general purpose, and the architecture to support the commercial/cloud offering causes some weird trade-offs when you are crafting test cases. As a url-blaster it's working fine for me, though. "modern developer focused" normally means elegant code like found on the (helpful link https://k6.io/blog/announcing-jmeter-to-k6-js-converter-tool https://k6.io/blog/announcing-jmeter-to-k6-js-converter-tool) const index = __ITER - ((__ITER / 2) | 0) * 2; switch (index) { case 0:

I just found out about k6, and I'm wondering why it's better than jmeter?

by robbyt 6y ago

I just found out about k6, and I'm wondering why it's better than jmeter?

You might get a less biased response from someone else, and I don't have much experience with JMeter, but: - k6 prioritizes modern developer experience. Tests are written in JavaScript, run from the CLI and can be committed to the same repository along with unit and integration tests. As such it blurs the line between responsibilities of a traditional QA team and pushes for load/performance/stress testing to be done by application developers themselves. This enables developers to easily integrate k6 in their existing CI pipelines and run load tests early on in the development cycle rather than as an afterthought. - k6 is written in Go, so it's much easier to deploy and use as a static binary, which also brings considerable performance benefits over JMeter. You can see a detailed breakdown and comparison in this article[1], written by another commenter here and one of the original k6 authors: rlonn. :) OTOH JMeter is a much more mature tool and has many more integrations and protocol support than k6. We recently launched an extension system for k6[2] that allows developers to add support for other protocols or features via native Go libraries, but the ecosystem is still in its infancy. So if you don't mind the JMeter UX, its performance or need some of its features, by all means stick with JMeter. But I would encourage you to give k6 a try for yourself, as it was written precisely out of the same frustrations mentioned in the article. [1]: https://k6.io/blog/comparing-best-open-source-load-testing-tools https://k6.io/blog/comparing-best-open-source-load-testing-t... [2]: https://k6.io/blog/extending-k6-with-xk6 https://k6.io/blog/extending-k6-with-xk6

liveoneggs 6y ago

it's easier to kick off in a jenkins pipeline since it's standalone but is otherwise less powerful, less general purpose, and the architecture to support the commercial/cloud offering causes some weird trade-offs when you are crafting test cases. As a url-blaster it's working fine for me, though. "modern developer focused" normally means elegant code like found on the (helpful link https://k6.io/blog/announcing-jmeter-to-k6-js-converter-tool https://k6.io/blog/announcing-jmeter-to-k6-js-converter-tool) const index = __ITER - ((__ITER / 2) | 0) * 2; switch (index) { case 0: