Skip to content

Add RequestResult.first_byte field for measuring first body byte latency #727

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

Merged
merged 1 commit into from
Apr 21, 2025

Conversation

jonilaitinen
Copy link

This adds an optional first_byte field which is set when the first byte of the response body is received. This enables collecting data for first byte latency during the tests.

There is also a new first-byte field added into the CSV output for each request.

@hatoo hatoo requested a review from Copilot April 10, 2025 10:53
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

@hatoo
Copy link
Owner

hatoo commented Apr 10, 2025

Adding a field to RequestResult increases overhead to the entire system.
I don't think the first_byte field is useful enough.

@jonilaitinen
Copy link
Author

Adding a field to RequestResult increases overhead to the entire system. I don't think the first_byte field is useful enough.

Is your concern that the RequestResult struct becomes too big (size of the struct in bytes is big)?

I've used the Response-delay (= first byte) and Response-read (= last byte) values in hey (see: https://github.com/rakyll/hey/blob/898582754e00405372f0686641441168f4e2f489/requester/print.go#L30-L31) because those values describe the viewer experience well (users care how fast they get the content). So I was hoping to get similar data with oha.

@hatoo
Copy link
Owner

hatoo commented Apr 12, 2025

Is your concern that the RequestResult struct becomes too big (size of the struct in bytes is big)?

Yes

I've used the Response-delay (= first byte) and Response-read (= last byte) values in hey (see: https://github.com/rakyll/hey/blob/898582754e00405372f0686641441168f4e2f489/requester/print.go#L30-L31) because those values describe the viewer experience well (users care how fast they get the content). So I was hoping to get similar data with oha.

Gotcha. I agree that collecting first_byte is good.
So, could you change the CSV column order and name to the same as hey?

This adds an optional `first_byte` field which is set when the first byte of the response body
is received. This enables collecting data for first byte latency during the tests.

There is also a new `first-byte` field added into the CSV output for each request.
@jonilaitinen
Copy link
Author

I've renamed the new field to be Response-delay in the CSV (same as hey).
For the column ordering, the current order is request-start,DNS,DNS+dialup,Response-delay,request-duration,bytes,status which seems logical to me as the events are in the order in which they happen (first request-start, then resolve DNS, connect to the server, and so on) or what do you think?

@hatoo hatoo merged commit eae5594 into hatoo:master Apr 21, 2025
18 checks passed
@hatoo
Copy link
Owner

hatoo commented Apr 21, 2025

For the column ordering, the current order is request-start,DNS,DNS+dialup,Response-delay,request-duration,bytes,status which seems logical to me as the events are in the order in which they happen (first request-start, then resolve DNS, connect to the server, and so on) or what do you think?

Looks good. Thank you!

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

Successfully merging this pull request may close these issues.

2 participants