-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(tracing): Add more network timings to http calls #8540
Conversation
There are enough now that we'll have to hide some in the UI, but we should be collecting all of these so we can better determine reasons for initial request delay.
size-limit report 📦
|
['http.request.fetch_start', resourceTiming.fetchStart], | ||
['http.request.domain_lookup_start', resourceTiming.domainLookupStart], | ||
['http.request.domain_lookup_end', resourceTiming.domainLookupEnd], | ||
['http.request.connect_start', resourceTiming.connectStart], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, is it on purpose that we changed this from:
(browserPerformanceTimeOrigin + resourceTiming.connectStart) / 1000
to just
resourceTiming.connectStart
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did intentionally do that, but I'm still trying to figure whether it makes more sense to align against browserTimingOrigin or just record the the values as is and change the representation internally. Mostly since I've seen these reported values be less than the wrapping span startTime
so something isn't adding up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually after thinking about it some more, I'm changing it back. Absolute time makes the most sense I think it's up to the sdk to provide time normalized against span
start/end time not a representation concern.
…tsentry/sentry-javascript into feat/tracing-add-more-network-timings
Summary
There are enough now that we'll have to hide some in the UI, but we should be collecting all of these so we can better determine reasons for initial request delay.