As we discussed internally in a recent sync, we would like to include and expose information about the metrics we display to the user. The general idea is that, in some manner, we would tell the user about what each graph displayed in the dashboard holds (metric data) and how they can be interpreted.
Although we haven't decided what that should look like yet, we agreed we should collect the "copy" for it so that we already have the information available when we move forward with its implementation. We discussed it internally in a recent sync, and we would like to include and expose information about it.
Note that a technical solution to this might be to include these descriptions directly in the output of k6 instead of storing them in the dashboard itself.
Suggested Solution (optional)
Here's a short description of the metrics we display in the dashboard. The information and copy are taken from the documentation. If you happen to have any improvement ideas or suggestions @heitortsergent, please don't hesitate to contribute 🙇🏻
Standard built-in metrics
vus (Gauge): Current number of active virtual users
vus_max (Gauge): Max possible number of virtual users (VU resources are pre-allocated, to avoid affecting performance when scaling up load )
iterations (Counter): The aggregate number of times the VUs execute the JS script (the default function).
iteration_duration (Trend): The time to complete one full iteration, including time spent in setup and teardown. To calculate the duration of the iteration's function for the specific scenario, try this workaround
dropped_iterations (Counter): The number of iterations that weren't started due to lack of VUs (for the arrival-rate executors) or lack of time (expired maxDuration in the iteration-based executors). About dropped iterations
data_received (Counter): The amount of received data. This example covers how to track data for an individual URL.
data_sent (Counter): The amount of data sent. Track data for an individual URL to track data for an individual URL.
checks (Rate): The rate of successful checks.
HTTP
http_reqs (Counter): How many total HTTP requests k6 generated.
http_req_blocked (Trend): Time spent blocked (waiting for a free TCP connection slot) before initiating the request. float
http_req_connecting (Trend): Time spent establishing TCP connection to the remote host. float
http_req_tls_handshaking (Trend): Time spent handshaking TLS session with remote host
http_req_sending (Trend): Time spent sending data to the remote host. float
http_req_waiting (Trend): 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 the 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
http_req_failed (Rate): The rate of failed requests according to setResponseCallback.
Browser
browser_web_vital_lcp (Trend): Measures a page's loading performance. Please refer to Largest Contentful Paint for more information.
browser_web_vital_fid (Trend): Measures a page's interactivity. Please refer to First Input Delay for more information.
browser_web_vital_cls (Trend) : Measures a page's visual stability. Please refer to Cumulative Layout Shift for more information.
browser_web_vital_ttfb (Trend): Measures the time it takes between the browser request and the start of the response from a server. Please refer to Time to First Byte for more information.
browser_web_vital_fcp (Trend): Measures the time it takes for the browser to render the first DOM element on the page, whether that's a text, image or header. Please refer to First Contentful Paint for more information.
browser_web_vital_inp (Trend): An experimental metric that measures a page's responsiveness. Please refer to Interaction to Next Paint for more information.
WebSockets
ws_connecting (Trend): Total duration for the WebSocket connection request.
ws_session_duration (Trend): Duration of the WebSocket session. Time between the start of the connection and the end of the VU execution.
ws_sessions (Counter): Total number of started WebSocket sessions.
ws_ping (Trend): Duration between a ping request and its pong reception
ws_msgs_sent (Counter): Total number of messages sent
ws_msgs_received (Counter): Total number of messages received
gRPC
grpc_req_duration (Trend): Time to receive response from remote host
grpc_streams (Counter): Total number of started streams
grpc_streams_msgs_sent (Counter): Total number of messages sent
grpc_streams_msgs_received (Counter): Total number of messages receivedof
Enhancement Description
As we discussed internally in a recent sync, we would like to include and expose information about the metrics we display to the user. The general idea is that, in some manner, we would tell the user about what each graph displayed in the dashboard holds (metric data) and how they can be interpreted.
Although we haven't decided what that should look like yet, we agreed we should collect the "copy" for it so that we already have the information available when we move forward with its implementation. We discussed it internally in a recent sync, and we would like to include and expose information about it.
Note that a technical solution to this might be to include these descriptions directly in the output of k6 instead of storing them in the dashboard itself.
Suggested Solution (optional)
Here's a short description of the metrics we display in the dashboard. The information and copy are taken from the documentation. If you happen to have any improvement ideas or suggestions @heitortsergent, please don't hesitate to contribute 🙇🏻
Standard built-in metrics
vus
(Gauge): Current number of active virtual usersvus_max
(Gauge): Max possible number of virtual users (VU resources are pre-allocated, to avoid affecting performance when scaling up load )iterations
(Counter): The aggregate number of times the VUs execute the JS script (the default function).iteration_duration
(Trend): The time to complete one full iteration, including time spent in setup and teardown. To calculate the duration of the iteration's function for the specific scenario, try this workarounddropped_iterations
(Counter): The number of iterations that weren't started due to lack of VUs (for the arrival-rate executors) or lack of time (expired maxDuration in the iteration-based executors). About dropped iterationsdata_received
(Counter): The amount of received data. This example covers how to track data for an individual URL.data_sent
(Counter): The amount of data sent. Track data for an individual URL to track data for an individual URL.checks
(Rate): The rate of successful checks.HTTP
http_reqs
(Counter): How many total HTTP requests k6 generated.http_req_blocked
(Trend): Time spent blocked (waiting for a free TCP connection slot) before initiating the request. floathttp_req_connecting
(Trend): Time spent establishing TCP connection to the remote host. floathttp_req_tls_handshaking
(Trend): Time spent handshaking TLS session with remote hosthttp_req_sending
(Trend): Time spent sending data to the remote host. floathttp_req_waiting
(Trend): Time spent waiting for response from remote host (a.k.a. “time to first byte”, or “TTFB”). floathttp_req_receiving
(Trend): Time spent receiving response data from the remote host. floathttp_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). floathttp_req_failed
(Rate): The rate of failed requests according to setResponseCallback.Browser
browser_web_vital_lcp
(Trend): Measures a page's loading performance. Please refer to Largest Contentful Paint for more information.browser_web_vital_fid
(Trend): Measures a page's interactivity. Please refer to First Input Delay for more information.browser_web_vital_cls
(Trend) : Measures a page's visual stability. Please refer to Cumulative Layout Shift for more information.browser_web_vital_ttfb
(Trend): Measures the time it takes between the browser request and the start of the response from a server. Please refer to Time to First Byte for more information.browser_web_vital_fcp
(Trend): Measures the time it takes for the browser to render the first DOM element on the page, whether that's a text, image or header. Please refer to First Contentful Paint for more information.browser_web_vital_inp
(Trend): An experimental metric that measures a page's responsiveness. Please refer to Interaction to Next Paint for more information.WebSockets
ws_connecting
(Trend): Total duration for the WebSocket connection request.ws_session_duration
(Trend): Duration of the WebSocket session. Time between the start of the connection and the end of the VU execution.ws_sessions
(Counter): Total number of started WebSocket sessions.ws_ping
(Trend): Duration between a ping request and its pong receptionws_msgs_sent
(Counter): Total number of messages sentws_msgs_received
(Counter): Total number of messages receivedgRPC
grpc_req_duration
(Trend): Time to receive response from remote hostgrpc_streams
(Counter): Total number of started streamsgrpc_streams_msgs_sent
(Counter): Total number of messages sentgrpc_streams_msgs_received
(Counter): Total number of messages receivedof