The analysis of your load results is a required step to find performance issues; a load test usually targets a service involving different subsystems and resources, making it hard to find the issue/s degrading your performance.
k6 provides two scripting APIs to help you during the analysis and easily visualize, sort and filter your test results.
- Groups: organize your load script around common logic.
- Tags: categorize your checks, thresholds, custom metrics and requests with tags for in-depth filtering.
Groups are optional, and it allows you to “group” a large load script to help you with the test result analysis. Groups can be nested, allowing you the BDD-style of testing.
For example, you could use groups to organize multiple requests due to loading a page or executing a user action.
Groups do the following tasks internally:
For each group() function, k6 emits a group_duration metric that contains the total time to execute the group function.
When a taggable resource: checks, requests, or custom metrics runs within a group, k6 will set the tag group with the current group name. Read more about it in Tags.
Both options, the group_duration metric and group tagging, could help you analyze and visualize better the results of more complex tests. Check out how they work in your k6 result output.
Discouraged use cases
Wrapping each individual request within a group might add boilerplate code and be unnecessary.
If your code looks like the example above, consider the following alternatives to write cleaner code:
- For dynamic URLs, use the URL grouping feature.
- To provide a meaningful name to your request, set the value of tags.name.
- If you need to model advanced user patterns, check out Scenarios.
Tags are a simple and powerful way to categorize your k6 entities for later results filtering.
k6 provides two types of tags:
- User-defined tags: the ones you've added when writing your script.
- System tags: tags automatically assigned by k6.
Currently, k6 automatically creates the following tags by default:
|proto||the used protocol name (e.g. HTTP/1.1)|
|subproto||the subprotocol name (used by websockets)|
|status||the HTTP status code (e.g. 200, 404, etc.)|
|method||the HTTP method name (e.g. GET, POST, etc.) or the RPC method name for gRPC|
|url||the HTTP request URL|
|name||the HTTP request name|
|group||the full group path|
|check||the Check name|
|error||a string with a non-HTTP error message (e.g. network or DNS error)|
|error_code||added in k6 v0.24.0, this is a number that is unique for different error types; a list of current error codes can be found at the Error Codes page|
|tls_version||the TLS version|
|scenario||the name of the scenario where the metric was emitted|
|service||the RPC service name for gRPC|
|rpc_type||one of unary, server_streaming, client_streaming or bidirectional_streaming for gRPC. Note: only unary requests are currently supported.|
If you choose, you could disable some of the above tags by using the systemTags option, just keep in mind that some data collectors (e.g. cloud) may require that certain tags be present. Also, you can enable some additional system tags, if you need them:
|vu||the ID of the virtual user that executed the request|
|iter||the iteration number|
|ip||The IP address of the remote server|
|ocsp_status||the Online Certificate Status Protocol (OCSP) HTTPS status|
User-defined tags allow you to categorize k6 entities based on your logic. The following entities can be tagged:
- custom metrics
Besides attaching tags on requests, checks and custom metrics you can set test wide tags that will be set across all metrics. You can either set the tags on the CLI using one or more --tag NAME=VALUE flags or in the script:
Read more about the k6 results output syntax to see how tags affect your test result output.
Additionally you can filter the results by tags in the analysis tab.