DEV Community

Marlo Henrique
Marlo Henrique

Posted on • Updated on

Performance test with K6: Knowing and Running Your First Test🏋️‍♂️

What are performance tests🤔

Performance testing refers to a subset of the software performance testing process.

When we refer to subset, this is due to several other types of tests that can be performed, focused on specific criteria, but which ultimately aim to measure the performance of the application.

In addition to the load test itself, we have other performance test examples, such as smoke test, stress test, immersion test, scalability tests.

What is K6🧐

k6 is a free and open source load testing tool that makes performance testing easy and productive for engineering teams.

Using k6, you can test systems reliability and performance and detect performance issues earlier, allowing you to build high-performance, resilient applications.

Although the scenarios are written in javascript, it is important to note that the K6 execution engine is based on Go.

k6 tool logo.

Why use K6 compared to other tools🤔

Today on the market we have several tools that are references when it comes to performance tests. Although Jmetter, Locust, Gatlin are already well-known tools on the market, the main point is where K6 stands out from the others.

resource usage: k6 is optimized to consume minimal resources and designed to perform high load tests.

performance monitoring: With k6, you can run tests with a small amount of load to continually validate the performance and availability of your production environment.

Types of tests that can be run📑

K6 allows us to run different types of tests, each serving a different purpose for our application. Each type of test seeks to present different information. Next, we will see each type of test better and how to apply them.

smoke Test

The smoke test or also known as smoke test is a regular load test, configured to use a minimum load in order to verify the sanity of the environment after insertion of new features.

load Test

The load test is a type of performance test performed to identify if the built application is meeting some performance goals, mainly in terms of users and requests that the system can meet per second.

Our objective here is not to break the system, but to obtain answers regarding the behavior of the system by simulating real-world scenarios.

stress Testing

Although it is very confused with the Load Test, both tests have different characteristics.

While Load Test is concerned with evaluating the performance of the system, stress testing is concerned with evaluating the system from the point of view of availability and stability under high loads. This type of test seeks to provide an answer to the following questions about your system:

  • How your system will behave under extreme conditions.
  • What is the maximum capacity of your system in terms of users or throughput.
  • Your system's breakpoint and failure mode.
  • If your system recovers without manual intervention after the stress test is over.

With all this information in mind, we can then go on to a little demonstration of execution.


  • K6 installed on your machine: for more details on installing k6

  • Any IDE of your choice installed: we are using VS Code


creating a folder for our project

Create a folder named k6-test to be used as a directory for our test scripts. If you use a command line tool like git bash or terminal on your system, just run the following commands:

// creating your directory
mkdir k6-test

// accessing the newly created directory
k6-test cd

// access directory in vs code
code .
Enter fullscreen mode Exit fullscreen mode

understanding the life cycle with K6

Before we start with the examples, it is important to clarify the lifecycle in a test with k6:

// 1. startup

export function setup() {
  // 2. settings

export default function (data) {
  // 3. VU code

export function teardown(data) {
  // 4. disassembly
Enter fullscreen mode Exit fullscreen mode

Understanding the structure of the script above:

  1. Step where we load local files, import modules, or declare global variables.
  2. Step where we configure data for sharing or data that will be used by the VU.
  3. Stage where the test function is executed, that is, where the scope of execution and creation of the test VU is concentrated.
  4. Step where we process the result at runtime.

Between the steps above, the only mandatory ones will be steps 1 and 2.

setting up our first test

For this example we will use the application ServeRest for testing. Create a file named teste.js, and add the following code to your file:

import http from 'k6/http';
import { sleep } from 'k6';

export default function () {
Enter fullscreen mode Exit fullscreen mode

Understanding the script above:

Note that we first scoped the imports needed for execution as defined by the initialization step.

The defined function has a test execution role (stage 3 of the life cycle), note that we initially have a get request followed by a 1 second sleep, that is, we will have a request being made by each VU every second.

We can run the above script using the following command:

k6 run teste.js
Enter fullscreen mode Exit fullscreen mode

And we will get the following result:

execution output results in the cli where test metrics and indicators are available.

setting options

One of the advantages of using options with K6 is that we can define some settings using stage 2 of the lifecycle. For example, for the above execution, if the user wants to define a greater number of VU's and a duration interval, he can add the following instructions:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',

export default function () {
Enter fullscreen mode Exit fullscreen mode

Now we have a code snippet where we define that our test will have 10 users, and will have a duration of 30 seconds.

After running the script, we will get the following output:

output results of execution in clt using load and duration of constant users, making metrics and test indicators available in the test results.

Note in the details of the results that we now have a maximum number of VU's reached, in addition to a greater number of requests made.

Increase and decrease of VU's in the execution

The adjustments we made in the previous execution, we defined a number of VU's that would already be available at the beginning of the test. Another possible scenario to be worked with K6 is the gradual increase and decrease in the number of users, also known as ramp-up and ramp-down

Let's make a new adjustment in the configuration step, but specifically in the scope of the option. Look at the code below:

export const options = {
  stages: [
    { duration: '10s', target: 10 },
    { duration: '20s', target: 10 },
    { duration: '10', target: 0 },
Enter fullscreen mode Exit fullscreen mode

Note that now as an option we have defined stages(stages) of the execution lifecycle that are divided into three stages:

  • Step 1 where the ramp-up from 1 to 10 users occurs within 10 seconds.
  • Step 2 where 10 user load is maintained for 10 seconds.
  • Step 3 where users ramp-down from 10 to 0 users within 10 seconds.

Executing our script again will have the following output:

output results of execution in clt using load and duration of variable users, making metrics and test indicators available in the test results.

Note that in the results details, despite a similar duration to the previous execution, the number of requests made is lower, due to the amount of VU's available during the execution.


K6 is a tool that, despite being new, already shows a lot of interest from the community for its simplicity and robustness, new plugins and tools are being developed for it, mainly aimed at reports with a great support from the community.

for more details about K6 see the official documentation of the tool 📎

Please feel free to connect on linked in for any questions or just to link up!😀

📩 linkedin
🐱‍👤 github

Top comments (0)