Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making the k6/experimental/tracing module part of the k6 core #3212

Closed
1 task
oleiade opened this issue Jul 19, 2023 · 1 comment · Fixed by #3854
Closed
1 task

Making the k6/experimental/tracing module part of the k6 core #3212

oleiade opened this issue Jul 19, 2023 · 1 comment · Fixed by #3854
Assignees
Labels

Comments

@oleiade
Copy link
Member

oleiade commented Jul 19, 2023

Feature Description

A few releases back, we introduced the k6/experimental/tracing module to k6.

Experimental modules intend to become part of the core eventually. Although the module has been around for a while, we have yet to take the opportunity to take a step back and consider what is left to do to reach a state acceptable to become a core module.

We are not aware of issues that would keep us from stabilizing this module at the moment, and unless some are raised, we will stabilize it sooner than later.

Tasks

Preview Give feedback
@mstoykov
Copy link
Contributor

mstoykov commented Feb 22, 2024

I have done a reimplementation in js here

Notes:

  1. if it is hitting a none existing localhost endpoint it seems to be around 80% slower
  2. the moment I started hitting something real not on localhost - this dissapered (also obviously the RPS plummetted)
  3. this lets you call instrumentHTTP and Client in not init context - while the go one doesn't. I find this to be a bug in the original version
  4. we don't really have a way to get nanosecond time in js - so I get millisecond time and multiply it by 1e6. Not certain how relevant that is. This also might slightly mess up the time as it goes in the theritory of float not being accurate. See Expose golang time module for microsecond and nanosecond granularity in custom metrics #2362
  5. while I have tested it somewhat locally - someone should definitely try it more with real traffic.
  6. edit: this also doesn't cap the provided arguments to 2 (body and params) but also pushes over any additional ones. While this is not really useful it won't break any potential detection that someone is misusing them by providing more arguments.

With this we can allow users to effectively do

import { instrumentHTTP, Client } from "/path/to/tracing-instrumentation.js";
 // including from jslib or directly from the gist or locally

// same as before

edit: I have now fixed instrumentHTTP and some other small issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants