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

feat(fetch): expose timings #32647

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

Skn0tt
Copy link
Member

@Skn0tt Skn0tt commented Sep 17, 2024

Closes #19621. Adds the same timings() we have for browser responses to APIResponse. Please apply some extra care in reviewing the timing calculations.

In the protocol change, I was unsure wether to extend the existing ResourceTiming type or to add another property. I went with the added property to be in-line with how the events work for browser requests - let me know if we should do it differently instead.

@Skn0tt Skn0tt self-assigned this Sep 17, 2024

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@Skn0tt Skn0tt requested a review from dgozman September 17, 2024 14:19
make responseEnd optional

make it more similar to existing types

missed one!
@Skn0tt Skn0tt marked this pull request as ready for review September 17, 2024 14:24
@@ -314,7 +314,7 @@ Returns resource size information for given request.
- `startTime` <[float]> Request start time in milliseconds elapsed since January 1, 1970 00:00:00 UTC
- `domainLookupStart` <[float]> Time immediately before the browser starts the domain name lookup for the
resource. The value is given in milliseconds relative to `startTime`, -1 if not available.
- `domainLookupEnd` <[float]> Time immediately after the browser starts the domain name lookup for the resource.
- `domainLookupEnd` <[float]> Time immediately after the browser ends the domain name lookup for the resource.
Copy link
Member Author

Choose a reason for hiding this comment

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

this is a drive-by fix - pretty sure it shouldn't say "start the domain name lookup"

This comment has been minimized.

This comment has been minimized.

@@ -483,6 +504,9 @@ export abstract class APIRequestContext extends SdkObject {
socket.on('lookup', () => { dnsLookupAt = monotonicTime(); });
socket.on('connect', () => { tcpConnectionAt = monotonicTime(); });
socket.on('secureConnect', () => { tlsHandshakeAt = monotonicTime(); });

// socks / http proxy
socket.on('proxyConnect', () => { tcpConnectionAt = monotonicTime(); });
Copy link
Member Author

Choose a reason for hiding this comment

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

Adding timings to the protocol uncovered that tcpConnectionAt was undefined for requests over SOCKS and HTTPS Proxy. Turns out that the library we use for that doesn't emit the connect event, but the proxyConnect event instead.

This comment has been minimized.

const endAt = monotonicTime();
// spec: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
const timing: channels.ResourceTiming = {
startTime: startAt,
Copy link
Contributor

Choose a reason for hiding this comment

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

The docs say startTime is a wall time, not monotonic time.

Copy link
Member Author

Choose a reason for hiding this comment

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

done in b717257

// spec: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
const timing: channels.ResourceTiming = {
startTime: startAt,
domainLookupStart: dnsLookupAt ? 0 : -1,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why zero and not relativeTime()?

Copy link
Member Author

Choose a reason for hiding this comment

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

My understand is that the browser has some other steps like cache resolution before the DNS lookup, so there might be time between startTime and the DNS lookup start. On Node.js, I don't think there's anything between that - so it's zero, because we know the DNS lookup happens immediately after the request start.

const timing: channels.ResourceTiming = {
startTime: startAt,
domainLookupStart: dnsLookupAt ? 0 : -1,
domainLookupEnd: dnsLookupAt ? dnsLookupAt! - startAt : -1,
Copy link
Contributor

Choose a reason for hiding this comment

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

relativeTime()?

Copy link
Member Author

Choose a reason for hiding this comment

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

done in b1d523b

body
body,
timing,
responseEndTiming,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we have two sets of timings now?

Copy link
Member Author

Choose a reason for hiding this comment

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

For browser requests, most of the timings are transmitted in the Response type, and then responseEndTiming arrives later in the requestFinished and requestFailed events. I opted to make this similar, so we have a big set of timings in timing and the final timing in responseEndTiming.

I thought about amending the ResourceTiming type instead, but then requestFinished would suddenly have the response end time both in responseEndTiming and in response.timing.responseEnd - that felt confusing.

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

Test results for "tests 1"

2 failed
❌ [playwright-test] › babel.spec.ts:135:5 › should not transform external
❌ [playwright-test] › fixture-errors.spec.ts:471:5 › should not give enough time for second fixture teardown after timeout

3 flaky ⚠️ [firefox-library] › library/inspector/cli-codegen-2.spec.ts:407:7 › cli codegen › click should emit events in order
⚠️ [playwright-test] › ui-mode-test-ct.spec.ts:59:5 › should run component tests after editing test
⚠️ [webkit-library] › library/download.spec.ts:698:3 › should convert navigation to a resource with unsupported mime type into download

35496 passed, 659 skipped
✔️✔️✔️

Merge workflow run.

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.

[Question] Is there a way to return an api request response time?
2 participants