31–40 of 86 posts
It seems like the hard part is deciding when a change is suspicious enough to be investigated? Simple pass/fail tends not to work at scale because complicated systems tend to be noisy.
Earlier quoted context omitted.
That's more or less it. Source: I am one of the k6 developers, and here's also an answer from our CEO on the topic: https://community.k6.io/t/k6-licensing-agplv3/395/2
The CEOs response doesn't inspire any confidence: If you statically or dynamically link any part of the k6 codebase with some other code (a derivative work), the license’s copyleft virality is triggered and that other code also needs to be made available under AGPLv3. When it comes to using the k6 binary and interacting with it from another process or over a network it is not certain exactly how the copyleft virality…
what is the max number of VUS you guys have run through it?
What is the benefit of this tool over vegeta or wrk2? I do like that vegeta and wrk2 work with simple http requests. If more complex flows and assertions on responses are required I go for Gatling. So maybe K6 is more comparable to gatling.
Personally I use autocannon which in my testing is faster than k6 and easier to use with a node.js environment. It is only a npm package, not a full software you need to install on your machine. Autocannon in my testing is 2 orders of magnitude faster than gatling, but you should do your own testing. PS. I have no affiliations to autocannon, I'm just a very happy user.
The only drawback compared to k6 is lack of websockets, which is unfortunate.
Reminds me of http://artillery.io - a modern, powerful & easy-to-use solution for load testing and synthetic monitoring
In their documentation ( https://k6.io/docs/ ) they claim that > JavaScript is not generally well suited for high performance. To achieve maximum performance, the tool itself is written in Go, embedding a JavaScript runtime allowing for easy test scripting. How is it possible that pure go JavaScript interpreter (goja) with bindings for net/http and some reports would be faster than the same tool written in nodejs usi…
I am not completely sure why the Go stdlib's HTTP client (which k6 uses) is faster than the NodeJS one. I think part of it is the fact that k6 spins up a separate JS runtime for each VU. goja is a much, _much_, slower JS interpreter than V8, but load tests are IO-bound, so that's usually not an issue. And you can spin up thousands of VUs in k6 (especially with --compatibility-mode=base), making full use of the load g…
Anyway, what I've seen when comparing the performance of tools, is that Artillery, which is running on NodeJS, is perhaps the wors performer of all the tools I've tested. I don't know if it's because of NodeJS or that Artillery in itself isn't a very performant piece of software (It also consumes a lot of memory, btw).
If you want the highest performance, there is one tool that runs circles around all others (including k6), and that is wrk - https://github.com/wg/wrk - very cool piece of software although it is lacking in terms of functionality so mostly suitable for simpler load testing like hammering single URLs.
(I don't know how fast wrk2 is, haven't benchmarked it)
What is the benefit of this tool over vegeta or wrk2? I do like that vegeta and wrk2 work with simple http requests. If more complex flows and assertions on responses are required I go for Gatling. So maybe K6 is more comparable to gatling.
Gatling is super slow. Suspicious slow in fact. You will likely not be able to really hit your endpoints hard enough by using one machine only. Personally I use autocannon which in my testing is faster than k6 and easier to use with a node.js environment. It is only a npm package, not a full software you need to install on your machine. Autocannon in my testing is 2 orders of magnitude faster than gatling, but you sh…
In my testing, Gatling isn't catastrophically slow by any means. Wrk, which is faster than any other tool I've seen, is about one order of magnitude faster than Gatling, in terms of raw RPS generation. I find it very hard to believe a NodeJS-based tool executing JS would be faster than the fastest tool written in C that just hammers static URLs.
How does it compare to Tsung?
We have a more comprehensive review of open source load testing tools in our blog (including Tsung): https://k6.io/blog/comparing-best-open-source-load-testing-t...
What I'm really excited to have discovered is the `HAR` format.
https://en.wikipedia.org/wiki/HAR_(file_format)
Over the past 10 years I have glued together project-specific variants of "parse some proxy or WAF log and spit out test or automation data" at least 4 or 5 times. Including as recently as a couple of weeks ago:
https://git.sr.ht/~tuxpup/parse-charles-log
Knowing HAR files existed would have saved me quite a bit of work and left me time to improve my automation or testing. I'm very happy to have discovered this.