Changing the UsersPerSession UMA metric to only count possible multi profile sessions and do this u…

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 1cfa48fbc4b33e07a84cddffee94218413878b39..8144534c865d14ce4a27f9ed834fe32ee0be8995 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -8073,7 +8073,7 @@ other types of suffix sets.
     counts are the number of discards and the buckets are the number of users.
     Since the count values are absolute numbers, they need to be normalized
     before use - so divide the counts by the percentage of users found under
-    'MultiProfile.UsersPerSession'.
+    'MultiProfile.UsersPerSessionIncremental'.

[Mark P, 2014/03/06 21:36:33]

The math still doesn't work.  Take my earlier example (did I forget to publish
it?) and suppose tons of tabs are evicted before the third user logs in.  You'll
still be dividing by 0 because you'll infer that no users were in two-user mode.

[Mr4D (OOO till 08-26), 2014/03/06 23:01:25]

Right. That is a possibility (but it unfortunately it won't happen as numbers
show ;) ).

Let's come back to what we want to do here: We want to show that with the
increasing amount of users the discarded tabs grow - and much more as linear
with a certain size. The question however is how many user it takes to get into
the "unstable area". There are power users which have 30+ tabs open and they
will get probably discarded tabs often - correct. But the most people will not.

The question which we try to answer is a "rough" number of users which make
sense to have (before running out of memory and the session gets ugly). There
are many factors (e.g. how much memory does the system have, how many tabs had
each user has open, what was in tabs (e.g. playing video)) but we only want to
look at it roughly statistically.

So now coming back to your comment:

You could logically assume that a session with 5 users consists of 5 separate
sessions (since no user can bail out without ending the session): one one user
session which ends when the second user logs in. That session ends when the
third user logs in and so forth.

So for all intents and purposes the percentage which is given under
"MultiProfile.UsersPerSessionIncremental" is *exactly* the value you are
interested in when doing the math as you indicated!

However ... If you go to the other extreme - each computer start would load all
users immediately before doing anything it would be incorrect and you should use
the "normalized" user counts instead.

So as usual the truth is somewhere in between the two extremes and you would
probably need to know the entire session length of *that* "segment" to be more
accurate, but in that case the memory configuration is much more important.
Where to stop? It's a rough estimate. :)

   </summary>
 </histogram>
 
@@ -8118,12 +8118,25 @@ other types of suffix sets.
 </histogram>
 
 <histogram name="MultiProfile.UsersPerSession">
+  <obsolete>
+    Deprecated 3/2014, renamed.

[James Cook, 2014/03/06 20:23:14]

Often we list the name of the stat it got renamed to.

[Mr4D (OOO till 08-26), 2014/03/06 23:01:25]

Done. (when adding this I glanced over the <obsolete> entries and the first 4 or
so I looked at had exactly this comment).

+  </obsolete>
   <summary>
     The number of users simultaneously signed into a multiprofile session on
     Chrome OS. This is recorded whenever a new user logs in.

[Mark P, 2014/03/06 21:36:33]

If this was actually recorded on shutdown, please correct this description.

[Mr4D (OOO till 08-26), 2014/03/06 23:01:25]

Done.

   </summary>
 </histogram>
 
+<histogram name="MultiProfile.UsersPerSessionIncremental">
+  <summary>
+    The number of users simultaneously signed into a multiprofile session on
+    Chrome OS. This is recorded whenever a user gets added to the session. To
+    get the correct count, all following counts must be subtracted. Example: If
+    100 single user, 20 two user and 5 three user sessions, there were
+    100-20-5=75 single user sessions, 100-80=20 dual user sessions and so on.
+  </summary>
+</histogram>
+
 <histogram name="NaCl.Client.Helper.InitState" enum="NaClHelperStatus">
   <summary>
     When the browser started, what happened with the NaCl helper process?