Add perf histogram and tests for inline signin

Add perf histogram and tests for inline signin

This CL adds a new histogram for measuring the total load time of inline login UI, and adds 3 telemetry tests based on the histogram. It also adds a new flag --force-signin-promo that forces showing the signin promo on startup for easier testing.

BUG=336963

[guohui, 2014-01-22 18:07:28]

Hey,

could you please take a look at the CL?

dtu@ for tools/...
xiyuan@ for the rest
and rogerta@ for all

Thanks,

Hui

[xiyuan, 2014-01-22 20:49:28]

Are we testing against real gaia server? It might not be a good idea to have
external dependency for testing.

What do we want to track from the UMA? It looks to me like that the biggest
contributor of the value is the Gaia loading time. I am not sure what we could
get out of it.

Also, it might be a good idea to file a bug to track the UMA, for things like
what is this UMA and why we are adding it etc.

[guohui, 2014-01-22 22:54:03]

On 2014/01/22 20:49:28, xiyuan wrote:
> Are we testing against real gaia server? It might not be a good idea to have
> external dependency for testing.
> 
> What do we want to track from the UMA? It looks to me like that the biggest
> contributor of the value is the Gaia loading time. I am not sure what we could
> get out of it.
> 
> Also, it might be a good idea to file a bug to track the UMA, for things like
> what is this UMA and why we are adding it etc.

yes it it is testing against real gaia server, but i think we can control
variables such as network conditions by recording the page set as described here
http://www.chromium.org/developers/telemetry/record_a_page_set, i ll investigate
it.

The main motivation for adding perf tests for inline signin is because based on
internal feedback, loading the  inline signin page is noticeably slower than
loading the embedded gaia webpage. We suspect the cause is due to the overhead
of creating a second renderer for the webview and of communication across
renderers. Thus we need histograms for the load time to get a better idea of the
magnitude of the issue, and to facilitate A/B testing.

Unfortunately, the existing load perf metrics are no good for testing pages with
webview. Almost all of them are based on document readystate event, and since
webview is launched asynchronously, the complete event of the parent fires
before the webview finishes loading. Thus this adds a new histogram and three
tests based on that.

Bug filed crbug/336963.

[xiyuan, 2014-01-22 23:23:28]

On 2014/01/22 22:54:03, guohui wrote:
> On 2014/01/22 20:49:28, xiyuan wrote:
> > Are we testing against real gaia server? It might not be a good idea to have
> > external dependency for testing.
> > 
> > What do we want to track from the UMA? It looks to me like that the biggest
> > contributor of the value is the Gaia loading time. I am not sure what we
could
> > get out of it.
> > 
> > Also, it might be a good idea to file a bug to track the UMA, for things
like
> > what is this UMA and why we are adding it etc.
> 
> yes it it is testing against real gaia server, but i think we can control
> variables such as network conditions by recording the page set as described
here
> http://www.chromium.org/developers/telemetry/record_a_page_set, i ll
investigate
> it.
> 
> The main motivation for adding perf tests for inline signin is because based
on
> internal feedback, loading the  inline signin page is noticeably slower than
> loading the embedded gaia webpage. We suspect the cause is due to the overhead
> of creating a second renderer for the webview and of communication across
> renderers. Thus we need histograms for the load time to get a better idea of
the
> magnitude of the issue, and to facilitate A/B testing.
> 
> Unfortunately, the existing load perf metrics are no good for testing pages
with
> webview. Almost all of them are based on document readystate event, and since
> webview is launched asynchronously, the complete event of the parent fires
> before the webview finishes loading. Thus this adds a new histogram and three
> tests based on that.
> 
> Bug filed crbug/336963.

Thank you for the explanation. 

LGTM then.

[Roger Tawa OOO till Jul 10th, 2014-01-23 02:09:37]

lgtm

[guohui, 2014-01-24 18:48:55]

Uploaded a new patch that records 4 histograms instead of 1. It splits the load
time of chrome://chrome-signin into 2 parts, pre-gaia-load-time and
gaia-load-time, also it separates load on startup from other cases.

+jar@ for tools/metrics/histograms.xml
+tonyg@ for tools/perf/...

[jar (doing other things), 2014-01-24 22:52:13]

https://codereview.chromium.org/134733019/diff/280001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/134733019/diff/280001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:17349: +    webview or iframe.
Can you expand on the prose to better distinguish the pair of histograms?  I
could barely find the difference in the text.

If you have to write a ton to be clearer, you *could* use a field trial to have
shared prose here, and the distinctive prose in the field trial for the two
cases... but it is not that big a win with the current minimalist prose.

[guohui, 2014-01-25 22:26:19]

On 2014/01/24 22:52:13, jar wrote:
>
https://codereview.chromium.org/134733019/diff/280001/tools/metrics/histogram...
> File tools/metrics/histograms/histograms.xml (right):
> 
>
https://codereview.chromium.org/134733019/diff/280001/tools/metrics/histogram...
> tools/metrics/histograms/histograms.xml:17349: +    webview or iframe.
> Can you expand on the prose to better distinguish the pair of histograms?  I
> could barely find the difference in the text.
> 
> If you have to write a ton to be clearer, you *could* use a field trial to
have
> shared prose here, and the distinctive prose in the field trial for the two
> cases... but it is not that big a win with the current minimalist prose.

sorry have to put this CL on hold. The underlying implementation may completely
change ...