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

Actual time to first byte metric for HTTP tests? #4074

Open
alexeyr-ci opened this issue Nov 18, 2024 · 4 comments
Open

Actual time to first byte metric for HTTP tests? #4074

alexeyr-ci opened this issue Nov 18, 2024 · 4 comments
Labels
awaiting user waiting for user to respond feature

Comments

@alexeyr-ci
Copy link

Feature Description

https://grafana.com/docs/k6/latest/using-k6/metrics/reference/ and #190 (comment) describe http_req_waiting as

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

However, when experimenting with a request where response is intentionally delivered in multiple chunks with a delay between them, it looks like http_req_waiting includes all the time waiting between chunks as well, because http_req_receiving is much smaller than the delays.

I'd like to know the time to the first byte as a proxy for time to the first chunk; currently I have to switch to browser tests for this, and TTFB there ends up being greater than the total http_req_duration for the HTTP test.

This information doesn't seem to be available in Response.timings either.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

@mstoykov
Copy link
Contributor

Hi @alexeyr-ci, sorry for the slow reply, the action assigning issues doesn't take github status into account :(

Looking at the code

https://github.com/grafana/k6/blob/master/lib/netext/httpext/tracer.go#L367

It seems like what you report should not happen. Do you have a reproducible example I can run.

Also the way receiving is calculated

trail.Receiving = done.Sub(time.Unix(0, gotFirstResponseByte))

I will expect either something is terribly wrong with our code or something with your code isn't working quite right.

@mstoykov mstoykov added awaiting user waiting for user to respond and removed triage labels Nov 29, 2024
@mstoykov mstoykov removed their assignment Nov 29, 2024
@alexeyr-ci
Copy link
Author

I have a reproducible example but it's in our private repository and probably too complicated, with both a JS server and a Rails server involved. I'll try to minimize it first, though it isn't a high priority for us, or just to get a permission to share the private repo.

@joanlopez joanlopez removed the triage label Nov 29, 2024
@joanlopez joanlopez removed their assignment Nov 29, 2024
@mstoykov
Copy link
Contributor

It definitely will be nicer for the reproducible example to be smaller and simpler :)

just to get a permission to share the private repo.

That probably will slow us down considerably if whoever has to look into this has to figure out all the things required to get it going.

@alexeyr-ci
Copy link
Author

It definitely would include the full instructions to reproduce, but let's hope minimizing it works first.

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

No branches or pull requests

4 participants