Load Testing in 2020 with k6!

Joel Ramos
ramosly | blog
Published in
5 min readJul 15, 2020

--

I was recently looking into the options for load testing tools.

On a previous project we had used Gatling, in which you write your tests in Scala. That worked well, and the reports were good, but now that I’m on a new team, I wanted to see what was out there.

And I was looking for something with which we could write tests in a more familiar language.

The tools I came across were these:

It was doubtful anyone on the team was gonna be familiar with Scala, nor am I a big Scala user. Python is probably the language I know the best, but only QAs use it here. The front-end folks all know JavaScript, and the API folks use Go, which pushed me more towards k6 and Vegeta.

All of these are open source by the way, and some have enterprise solutions.

Vegeta looked like it would get the job done. It’s basically a github repo with a README and some instructions on how to install it, run it, etc.

k6 looked much more polished/full-featured. You write tests in JavaScript, it’s console output is clean, and it can output to DataDog, Kafka, and more.

Since k6 just looked friendlier to use, and I’m more familiar with JavaScript anyway, I decided to give it a whirl!

Taking k6 for a spin

If you’re on a Mac, you can just brew install k6

Sweet.

They also have a docker image which is also cool, but I went with brew for now.

I created a folder named k6 on my computer.

I created a script.js file and followed the documentation to get started.

You might notice that I have a package.json file. I ran yarn init to initialize my project here expecting that I would have to install packages. But evidently, brew-installing k6 was enough and these imports worked 🤷‍♂️

more on this later 👀

Anyway…

Now that I had created the script.js file, all I had to do was run it.

$ k6 run script.js

Here, you can see that vus (virtual users) is 1 by default, as is vus_max.

If we want to up those numbers, we can pass them as options.

This time, I had k6 run with 10 virtual users, and hit the server for 30 seconds.

test.k6.io

You probably noticed that the script is hitting test.k6.io.

That’s another cool thing about k6 is that they have a test environment for you to run tests against. If you navigate to http://test.k6.io you’ll see other urls they have that you can hit to test different things 🤯

Assertions or “checks”

Next task was to add a check to verify that we get a 200 response from the server.

Enter script2.js

  1. I added the comments which were in the documentation. Evidently, setup code should live outside the default function. Virtual user code should live inside the default function.
  2. In addition to importing the sleep function from k6, I've imported the check function. Then, rather than discarding the response form http.get() it is stored in a res variable, passed to check() where its status is compared to 200

And now, when I run script2.js

k6 run --vus 10 --duration 30s script2.js

🎉

This is awesome!

And the documentation keeps going. They distinguish between load tests and stress tests. They go over how to ramp up the load over time, hold the load steady, and then ramp down.

I think the k6 folks did such a good job with the experience of not just using the tool, but also following their documentation and interacting with their test environment, that I actually want to load test and play k6 more.

Caveats

The k6 docs note two trade-offs of using k6 in the What k6 does not section.

  1. The first is that it does not run in a browser and so, “does not render webpages the same way a browser does.” So you might get misleading results if you are hitting urls for webpages rather than hitting API endpoints.
  2. The second is that it does not run in Node, which was eluded to in the beginning. Since it’s actually written in Go but just letting you write scripts in JavaScript, there are extra steps you’d have to do in order to import external modules.

And #2 explains why I didn’t need to yarn add any npm packages.

And they have VS Code extensions?!

And they have TypeScript types, in which case you would use yarn or npm to initialize the project with a package.json file and then install @types/k6 to get the intellisense in VS Code.

I’m curious if anyone else out there has been using it and has come across any other gotchas.

But anyway, for load and stress testing (in non-production environments!) I think this k6 tool looks super cool!

--

--

• Economics grad from UC San Diego • QA Engineer • Pythonista • Always learning!