tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index d51e0645a245845bb7e73e3b994bdfcbdbbf0277..5f3cfa96ef2daa49ccd1980c7fc1473124ea91eb 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -35863,6 +35863,14 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   </summary>
 </histogram>
 
+<histogram name="WebCore.IndexedDB.OpenTime" units="milliseconds">

[jsbell, 2014/08/14 22:58:06]

I'm not sure we should measure all of these using the same histogram. It would
be hard to determine what a "typical" open looks like if some unknown fraction
fail very quickly.

The common cases seem to me to be:

open -> upgrade -> success (new or updated database)
open -> success (existing database, or another tab is upgrading)
open -> blocked -> upgrade -> success (upgrade, but other connections busy)
open -> upgrade -> error (upgrade aborts: rare!)
open -> error (some internal error like quota: rare!)

... or at least reflect that what we're measuring is 'time to first event' in
the histogram name, although it's not necessarily being opened.

[dgrogan, 2014/08/14 23:29:12]

I had similar thoughts. There's a good chance this data won't lead to any
insights because it's measuring such disparate code paths.

Open->success should be nearly instantaneous when the backing store is already
open and the requested version matches the current version.
Open->success will be measuring a bunch of disk activity if the backing store is
not already open.
Open->upgradeneeded could include time used by other tasks on the IDB thread
before VersionChangeOperation runs in addition to disk activity.
Open->blocked will measure a bunch of IPCs
etc

After thinking about it a bit I think you want one histogram per event type, as
Josh alluded to. Thoughts?

[cmumford, 2014/08/14 23:53:03]

No problem. I figured this change would require a different approach so
separated it from the previous CL for that reason. Do you two think I should
support all five cases, or maybe just the first three "success" cases?

On 2014/08/14 22:58:06, jsbell wrote:

[jsbell, 2014/08/15 00:05:16]

I think the first three is probably enough.

Understanding these numbers is probably going to require some thought.
open->success is easy to reason about. open->upgrade->success is dependent on
how much work the site's upgrade code does. open->blocked->upgrade->success is
dependent on that *plus* how long any other connections linger. A poorly
implemented site could cause the latter number to spike even if Chrome didn't
change (we had a bug report like that recently where a Chrome app started
blocking its own upgrades!)

But we shouldn't overthink things here, as long as we're distinguish these
cases. The important thing is being able to replicate reports from $CUSTOMERS
who say some fraction of opens are very slow. Let's measure what's easy and go
from there.

[dgrogan, 2014/08/15 02:09:30]

I thought we were just going to measure the time until the backend decides which
event it will fire _first_. In which case the site's upgrade code is irrelevant.
That's the data we're getting from customers, right? The time to _first_ event?

Though open->success will still be bimodal, one peak for the already-opened case
and another (very broad) peak for the not-yet-opened case.

+  <owner>cmumford@chromium.org</owner>
+  <summary>
+    The time that it takes to open an IndexedDB database and fire the first
+    event - one of: onerror, onsuccess, onblocked, onupgradeneeded.
+  </summary>
+</histogram>
+
 <histogram name="WebCore.PreloadDelayMs" units="milliseconds">
   <owner>Please list the metric's owners. Add more owner tags as needed.</owner>
   <summary>