Closed k-berger closed 8 years ago
Hi @k-berger: You are correct, all restiming
start times are relative to navigationStart
. So for SPAs, where the application is kept open for a long time and navigationStart
doesn't change, you should see monotonically increasing startTime
values on SPA restiming
beacons.
59bv0,7,7,2
translates into [element type][startTime],[responseEnd],[responseStart],[requestStart]
element type = XHR
startTime = parseInt("9bv0", 36) = 435276
or 435 seconds since navigationresponseEnd = startTime + parseInt("7", 36) = 435283
responseStart = startTime + parseInt("7", 36) = 435283
requestStart = startTime + parseInt("2", 36) = 435278
@k-berger Can we close this issue?
Closing, please re-open if this is still an issue.
Hi,
I built boomerang and am successfully sending beacons to my backend. However to me it seems as if there was a problem with getting the correct start-time for - at least - AJAX calls on SPA (AngularJS in this case). My test-app contains a controller which will call a REST-API to retrieve some data. What I see is, that the start-time for this call in the resourcetiming-trie is monotonically rising. Somehow in "findPerformanceEntriesForFrame" boomerang will retrieve huge offsets, which are likely related to the start-time of the app - not of the navigation. So after all the start-time of these calls does not seem to be related to the navigation.
restiming={"http://local-instana.instana.io:5000/api/values":"59bv0,7,7,2"}
when I understand correctly, "9bv0" is meant to be the starttime in milliseconds relative to the navigation-start. Am I wrong here, is this a bug, are something one has to work around?
Thanks your help!