Dashboards representing individual transactions' metrics rather than TOTALs

[netikras]

Feature Description

Maybe the feature is already there, but I'm having the hardest time finding it being mentioned anywhere.

So, I come from the background of JMeter and HP LoadRunner. Both are great tools and both of them can visually represent metrics in graphs. The graphs show metrics for each transaction separately. I.e. suppose I'm testing 3 APIs in the same test: POST /login → GET /cart → POST /cart/order. I'd like to see in the graphs (aggregated) metrics plotted for each of those transactions separately, i.e. the TPS graph would have 3 (4?) lines: 1 - rate(login), 2 - rate(getCart), 3 - rate(submitOrder) (, 4 - TOTAL).

All the examples I see seem to only have the TOTAL line in all the metrics' graphs. I tried running my test myself and I also see the TOTALs.

Does the xk6-dashboard already have this feature? If not - could it be implemented? In the output.json (k6 --out json=out.json) seems to have those tx names
For the rendering overhead, the HP LoadRunner's approach could be leveraged -- by default plot max 10 transactions, and the others could be selected for rendering by clicking on their names in the legend (similarly to how Grafana TS graphs show/hide metrics by clicking on them on the legend)

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

• [151] clicking on a legend item to filter rendered metrics' graphs

[szkiba]

Hi @netikras , Thanks for the suggestion. The dashboard works with aggregated values. Aggregation is not currently supported on a per-URL basis. Aggregated values are created based on tags, but the UI has not yet display them. Display based on tags is a planned feature. Unfortunately, I cannot give you a deadline, but we will keep it in mind.

[netikras]

Hello @szkiba, thanks for the explanation. Yes, aggregation based on tags should represent the concept of 'transaction' best, as a single 'transaction' may contain several operations in some cases. If I understood you right, the aggregation by-tags is (mostly) implemented in backend, it's just the frontend that needs to "be taught" how to represent the data?

On a side note, should I want to test the future latest version of your extension, how can I do that? The latest k6 release embeds the dashboard extension and if I try to xk6 build it with you ext. launching k6 seems to be failing with ERRO[0000] invalid output extension web-dashboard, built-in output with the same type already exists

[szkiba]

Hi @netikras

If I understood you right, the aggregation by-tags is (mostly) implemented in backend, it's just the frontend that needs to "be taught" how to represent the data?

Exactly

On a side note, should I want to test the future latest version of your extension, how can I do that? The latest k6 release embeds the dashboard extension and if I try to xk6 build it with you ext. launching k6 seems to be failing with ERRO[0000] invalid output extension web-dashboard, built-in output with the same type already exists

Thank you for bringing this to my attention. The original idea was that the built-in module name and the output extension name would be different, which would have made it possible to test the next version as an extension. In the process, the built-in module and the extension had the same name, which really does not allow testing and use as an extension because the name conflicts with the built-in module name.

I have created a dedicated issue for this problem where you can follow its status: #162