We see some strange, very high elapsed times via activity tracking, specifically for the default "Loaded App" track. My hunch is that this relates to browsers suspending inactive tabs and then resuming them later (I know this is imprecise language here, not sure of the exact mechanism).
It would be good to really get to the bottom of what is happening, but the end result is that we currently see "impossible" tracked times - e.g. 12 minutes to load the app. Even on a very slow connection that takes a while to download the source, it doesn't seem possible, especially given that initial blocking API calls all have timeouts applied.
Proposing that we support new options in our xhActivityTrackingConfig JSON config to spec a max elapsed time that we will record. If a track comes in over that, we null out the time so as not to throw off aggregate stats (e.g. status monitor for recent average load times).
Considered "stashing" the time that was reported in the data object as an extra option - or we could log it, or we could just forget it completely. Motivation there is to provide some support to later troubleshooting, but you would always have the option of temporarily removing the cap to collect / analyze some long times. So unless anyone feels strongly we should do it, I am happy to leave that idea aside until some clearer need for it arises.
I don't like putting in some option to workaround a mystery behavior here, but it also seems like browser behavior, mobile connectivity, etc. are always going to be a bit of a moving target, and that if there will always be some exposure to randomly, implausibly high times being reported, would be good to have a mechanism to keep our stats useful and sane.
We see some strange, very high elapsed times via activity tracking, specifically for the default "Loaded App" track. My hunch is that this relates to browsers suspending inactive tabs and then resuming them later (I know this is imprecise language here, not sure of the exact mechanism).
It would be good to really get to the bottom of what is happening, but the end result is that we currently see "impossible" tracked times - e.g. 12 minutes to load the app. Even on a very slow connection that takes a while to download the source, it doesn't seem possible, especially given that initial blocking API calls all have timeouts applied.
Proposing that we support new options in our
xhActivityTrackingConfigJSON config to spec a max elapsed time that we will record. If a track comes in over that, we null out the time so as not to throw off aggregate stats (e.g. status monitor for recent average load times).Considered "stashing" the time that was reported in the data object as an extra option - or we could log it, or we could just forget it completely. Motivation there is to provide some support to later troubleshooting, but you would always have the option of temporarily removing the cap to collect / analyze some long times. So unless anyone feels strongly we should do it, I am happy to leave that idea aside until some clearer need for it arises.
I don't like putting in some option to workaround a mystery behavior here, but it also seems like browser behavior, mobile connectivity, etc. are always going to be a bit of a moving target, and that if there will always be some exposure to randomly, implausibly high times being reported, would be good to have a mechanism to keep our stats useful and sane.