logging UMA from render process and fast shutdown

[Bryan McQuade]

Hi,

I've been working on improving the accuracy of PageLoadHistograms (https://code.google.com/p/chromium/codesearch#chromium/src/chrome/renderer/page_load_histograms.h) UMA metrics. PageLoadHistograms records UMA metrics like the time from navigation started to first paint, time from navigation started to dom content loaded, etc. We'll be increasingly dependent on these metrics as we evaluate changes to improve loading performance using field trials, so it's important that they accurately capture real user experience.

PageLoadHistograms records its metrics in a RenderViewObserver::FrameWillClose() callback. This is a convenient point to hook in and record all metrics that were recorded during the lifetime of the page.

Unfortunately, due to fast shutdown, this callback is not called for many closed tabs. This means our UMA statistics end up missing data for many web page loads.

A few options I see:

We could try to record the UMA metrics at the time that each event happens, e.g. at the time of first paint, or the time DOMContentLoaded fires, etc, rather than waiting until the FrameWillClose callback. However, most of these events are recorded in blink (and need to continue to be recorded that way since the loading metrics we record in UMA are exposed on window.performance.timeline as well), and there's currently no callback from blink->chrome for them. We could add callbacks for each event from blink to chrome, but that introduces complexity that would be nice to avoid.

We could poll every so often to see which events were ready to be logged, but this seems undesirable.

A third option would be to introduce an IPC from browser to renderer that happens just before fast shutdown, to tell the render process that it's about to be killed and should log/persist any data that needs to be stored. The browser process would wait for an ACK IPC from the render process, or short timeout, before performing the actual process kill. This would give the render process a last chance to save away any state that's important, before being killed.

I'm interested to hear whether such a mechanism to message from browser to render process at fast shutdown exists currently, and if not, whether it might make sense to add it. Does having the ability for a render process to log or persist data back to the browser process before fast shutdown seem like a useful addition?

Thanks,

Bryan

[Gabriel Charette]

We should avoid communication with renderers on shutdown. Renderers responsible for hidden content (e.g., background tabs) will actually be running at lower process priority and may not respond in a reasonable time.

Communicating with renderers on shutdown is problematic because it results in trashing scenarios where renderers that were potentially paged out per inactivity have to be paged back in solely to be killed (this is actually a problem today with onClose() handlers).

If you need to persist stats on shutdown I suggest you instead have the renderers update a cache in the browser every now and then and have the browser flush that on shutdown without having to communicate back with the renderers, would that work for you?

Cheers,

Gab

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Bryan McQuade]

On Tue, Jul 21, 2015 at 12:28 PM Gabriel Charette <g...@chromium.org> wrote:

We should avoid communication with renderers on shutdown. Renderers responsible for hidden content (e.g., background tabs) will actually be running at lower process priority and may not respond in a reasonable time.

Communicating with renderers on shutdown is problematic because it results in trashing scenarios where renderers that were potentially paged out per inactivity have to be paged back in solely to be killed (this is actually a problem today with onClose() handlers).

If you need to persist stats on shutdown I suggest you instead have the renderers update a cache in the browser every now and then and have the browser flush that on shutdown without having to communicate back with the renderers, would that work for you?

Makes sense. I think your proposal of pushing data back to the browser process and making the browser process responsible for logging data should work.

Thanks!

-Bryan

[Dale Curtis]

FWIW, browser-side storage is how we log several media pipeline statistics since our problem is similar with the additional wrinkle of dealing with garbage collected objects.

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/media/media_internals.cc&l=260

- dale

[Christian Biesinger]

+blink-dev

I just wanted to note that this is already a problem today for blink's UseCounter data, so thanks for thinking about this. If a solution could include use counters / CSS usage data, that'd be great.

-christian

--

[David Dorwin]

Is there a bug for the Blink UseCounter issue? If not, I'll file one.

To expand on this, it appears that some UseCounters (WebCore.FeatureObserver histograms) are only persisted when navigating to a page on the same origin. They do not appear to be persisted without navigation, when navigating to a different origin, or closing the tab.

The specific UseCounters I observed are related to JS calls. I can see the usage being reported to Chromium, but it never shows up in chrome://histograms/ unless i navigate to a page in the same origin. Related UMA metrics on the Chromium side are visible in chrome://histograms immediately.

David

[Christian Biesinger]

Sorry, I am not sure if a bug is filed on UseCounter and I can't
currently find one. The behavior you describe is indeed what I'm
referring to.

-christian

[Nasko Oskov]

I think the same is true for tracing data, which prevents us from collecting traces when doing cross-process navigations and some browser tests. I'm all for finding a common solution to all of these cases. 

[David Dorwin]

For future reference, I filed a bug specifically for the Blink UseCounter issue: https://code.google.com/p/chromium/issues/detail?id=513059

[Bryan McQuade]

Awesome! We'll follow your progress and see if we can learn from/reuse your work. Thanks for taking this on!

-bryan

On Wed, Jul 22, 2015 at 11:32 PM Renée Wright <rjwr...@google.com> wrote:

This is related to this: https://code.google.com/p/chromium/issues/detail?id=322355

I am going to start working on the use-counter aspect of it today.

Renée

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Charles]

Hey folks, Bryan and I have been working on a solution for this issue on our end. Here's a link to the design doc describing our approach. We're basically looking at propagating a notification out of Blink when a metric updates, so we can pull the data and send it to the browser process via IPC. Comments and suggestions welcome!

-Charlie

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.