855385 - Isolate impact of application updating on process start times

Status: RESOLVED INCOMPLETE

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P4)

Description

[Gregory Szorc [:gps]]

I've noticed that the process startup times reported by FHR via nsIAppStartup *seem* to include time spent running the installer/upgrader. This will add seconds to reported times and possibly result in incorrect identification of slow startup.

I think we should identify whether startup was delayed by a process not under the user's control (like installer) and report or adjust for this in the reported times.

rstrong: could you please provide info on how the installer/upgrader works in terms of process lifetime, specifically how it would impact measurement of startup/shutdown times.

Comment 1

[Robert Strong (they/them - no direct email)]

Startup checks if there is an update pending and if it is it applies the update.
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3464

The firefox process exits while the update is applied. This should happen once approximately every 6 weeks on the release channel if there are no security updates. We have lessened the impact by applying the update to a staged copy and swapping this with the original. With the previous in mind I don't think there is much more we can reasonably do to lessen the impact of there being one startup to to apply an update approximately every 6 weeks. I suspect you could flag startups that need to apply an update in your measurements. Perhaps even report it separately so we can see if startup times which need to apply an update change significantly.

Comment 2

[Gregory Szorc [:gps]]

Flagging startups that incurred an update would possibly help with data analysis. Currently, we have no way of knowing if they were an expected or unexpected outlier.

Is there any way to determine whether the current session incurred an update?

Comment 3

[Robert Strong (they/them - no direct email)]

The flow is essentially
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3508
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#912
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#978
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#647
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsUpdateDriver.cpp#857
which is followed by exit(0) when restart evaluates to true

Comment 4

[Gregory Szorc [:gps]]

So, I guess the question is whether FHR's session recorder (initialized during profile-after-change notification) is initialized when an update is running.

I don't pretend to know my way around nsAppRunner.cpp to know for sure. I guess it's time to go code diving!

Comment 5

[Robert Strong (they/them - no direct email)]

Changing summary to avoid confusion with the installer.

Comment 6

[Mike Connor [:mconnor]]

I'm not sure, but I'd suspect that this should really be a bug against the startup component, rather than being FHR-specific, since there are other consumers of this data.

Comment 7

[Thomas Huelbert]

investigate on unified telemetry

Comment 8

[Thomas Huelbert]

Hey Stephen, is this something your current work overlaps with? And if so, do you want to take this? If not, we'll close, thanks.

Comment 9

[Stephen A Pohl [:spohl]]

No, this doesn't overlap and it would rank pretty low on my list of priorities if I were to take it, sorry.

Comment 10

[Robert Strong (they/them - no direct email)]

As far as updates go the following pref which is provided by app update can be checked by the telemetry code prior to it being cleared.

https://dxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1224

This of course won't handle the case of a secondary user that had Firefox updated (whether that is by a pave over install or an app update) by someone else or the case of using multiple profiles with the same install since the pref is specific to the profile used immediately after an update. I know in the past that those users can have startup affected by the regeneration of the xul cache, etc. though I don't know the status of that now.

Comment 11

[Firefox Bug Husbandry Bot]

Closing abandoned bugs in this product per https://bugzilla.mozilla.org/show_bug.cgi?id=1337972