Embrace the magic of K6

With the growing need for having highly scalable enterprise software systems, most of the development efforts nowadays go toward using microservice architecture. One of the top advantages of using such an architecture is being able to easily scale any of your services based on the load.

The problem now is having an initial understanding of how your service is going to respond in any load and find answers to questions like "Are there any code smells, blocking I/O calls, not-optimized database queries, cache problems.... exist that affect directly or indirectly on your service's capability to handle specific load within specific resources?".

For finding answers to the aforementioned question, you need to simulate concurrent service calls caused by concurrent users. Implementing this scenario correctly is not an easy task if you want to implement it yourself and develop it from scratch. Instead, you can utilize several load test tools available freely to save your time. One of these tools is K6. I am not saying that this is the best solution for every possible scenario but as a JavaScript coder, I truly love the simple and readable way to write our test scenario with JavaScript. So, let's dive deeper into how we can use K6 as a load test tool in most scenarios.

One of the reasons that I recommend using K6 is that it can easily be integrated with time series databases like InfluxDB to send the measures and results directly into the database and by using visualization tools and dashboards like Grafana all the results can be analyzed and visualized.

First of all, there is no need to be worry about installing anything because K6 is container friendly so the only thing that you need is to pull its docker image in your docker-compose file or directly from the command line.

Figure 1   K6 service inside a docker-compose file

As you can see in figure 1 the integration with InfluxDB can be easily set via Environment Variables. It is highly recommended that put your K6 service in the same network with your target API to test (for instance the network with the name “k6” in figure 1). Now the last part is to tell the docker where your script files are located. In this example, I put my K6 tests in the “load_test/k6_test” which is a relative address to the docker-compose file. Now it is time to see how our test files are written.

As I already said, tests that are written in K6 is pure Javascript. At the top of the file, we have to import some modules to work with HTTP requests (REST APIs) and check whether the results are acceptable or not (assert results).

Figure 2 import required modules at top of the file

And inside the file, you have to export your module so that K6 can call it from its virtual users. In this simple example I am going to call authorize API, send my username and password and check the JSON result with HTTP status code and JWT token that is sent back from my API.

Figure 3 exported function (the main scenario of your test happens here)

In line 10 (figure 3), I defined my parameters that will be sent to the API as a Javascript object. In line 12, I defined my request headers (in its simplest form) and finally, in line 13, I called my endpoint through “http” module of K6 and passed the parameters and headers that I already have defined. In line 15, I parsed the result sent back from API, and finally through lines 17 to 20, I checked the results with what I have expected. The object type that K6 returns contains the status code of the response, the returned result, and a bunch of other useful properties. In this simple example, I just checked the status code of the response to make sure that no errors occurred at the server-side and also checked the length of the value returned as a JWT code (just checked the length not the content itself). Now that everything is ready it is time to do some tests! You have already defined your InfluxDB service and Grafana service inside your docker-compose file as you can see in figure 4.

Figure 4 InfluxDB and Grafana service definitions in the docker-compose file

As you can see in figure 4, Grafana needs to be in the same network with InfluxDB and InfluxDB needs to be in the same network with K6. (we have already defined K6 service in this network in figure 1)

Next, you can run all your services except the K6 with this simple docker-compose command.

Figure 5 run all services except K6

It is time for running your test. Simply run this docker-compose command to start your k6 service as a part of your docker-compose to test your API.

Figure 6 run k6 with its command-line arguments

There are somethings to explain in figure 6. As you can see I am passing to K6 service, the command “RUN” and this command requires arguments like the location where the tests are, and the number of virtual users (--vus “the number of virtual users”), and the number of total iterations that all virtual users together complete (--iterations “total number of runs”). The number of iterations is a little bit tricky because it does not determine the number of iterations for each virtual user but it determines the total number of runs. Therefore, in this example, we have 1 virtual user with 2 iterations that means my single virtual user will call API 2 times. If I had, for instance, --vus 2 –iterations 2, it would have meant every single virtual user calls my API only once and in the end, I have 2 calls of my APIs.

Figure 7 aggregated result in terminal

Figure 8 Grafana dashboard

In Figure 7 you can see the aggregated result of all calls in your terminal and also you have the option to visualize the results in your Grafana dashboard while your test is running..

In this article, I tried to introduce you to the basic functionality of K6 and the way it can be used to simulate your production environment. There is much much more to know about this handy tool. Hope it helps.