A modern load testing tool, using Go and JavaScript

"like unit testing, for performance"

k6 is a modern load testing tool, building on Load Impact's years of experience. It provides a clean, approachable JavaScript scripting API, distributed and cloud execution, and orchestration via a REST API.

k6 REST API

Recent Posts

Archive

Metrics

This section covers the important aspect of metrics management in k6. How and what kind of metrics k6 collects automatically (built-in metrics), and what custom metrics you can make k6 collect.

Built-in metrics

The built-in metrics are the ones you can see output to stdout when you run the simplest possible k6 test, e.g. k6 run github.com/loadimpact/k6/samples/http_get.js which will output something like the below:

All the http_req_... lines and the ones after them are built-in metrics that get written to stdout at the end of a test.

The following six built-in metrics will always be collected by k6:

Metric name

Type

Description

vus

Gauge

Current number of active virtual users

vus_max

Gauge

Max possible number of virtual users (VU resources are preallocated, to ensure performance will not be affected when scaling up the load level)

iterations

Counter

The aggregate number of times the VUs in the test have executed the JS script (the default function). Or, in case the test is not using a JS script but accessing a single URL, the number of times the VUs have requested that URL.

data_received

Counter

The amount of received data.

data_sent

Counter

The amount of data sent.

checks

Rate

Number of failed checks.

HTTP-specific built-in metrics

There are also built-in metrics that will only be generated when/if HTTP requests are made:

Time spent waiting for response from remote host (a.k.a. "time to first byte", or "TTFB"). float

http_req_receiving

Trend

Time spent receiving response data from remote host. float

http_req_duration

Trend

Total time for the request. It's equal to http_req_sending + http_req_waiting + http_req_receiving (i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times). float

Accessing HTTP timings from a script

If you want to access the timing information from an individual HTTP request, the built-in HTTP timing metrics are also available in the HTTP Response object:

Counter (cumulative metric)

The value of my_counter will be 3 (if you run it one single iteration - i.e. without specifying --iterations or --duration).

Note that there is currently no way of accessing the value of any custom metric from within Javascript. Note also that counters that have value zero (0) at the end of a test are a special case - they will NOT be printed to the stdout summary.

Trend (collect trend statistics (min/max/avg/percentiles) for a series of values)

A trend metric is really a container that holds a set of sample values, and which we can ask to output statistics (min, max, average, median or percentiles) about those samples. By default, k6 will print average, min, max, median, 90th percentile and 95th percentile.

Rate (keeps track of percentage of values in a series that are non-zero)

The value of my_rate at the end of the test will be 50%, indicating that half of the values added to the metric were non-zero.

Notes

custom metrics are only collected from VU threads at the end of a VU iteration, which means that for long-running scripts you may not see any custom metrics until a while into the test.

Metric graphs in Load Impact Insights

If you use Load Impact Insights, it can draw all the metrics as shown on the screenshot below. By default it shows only very basic metrics, but you will be able to add both system and custom metrics as more graphs, or as different metrics on the same one.