Add new histograms to track down cookie performance issues.

Add new histograms to track down cookie performance issues.

BUG=105921
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=113231

[erikwright (departed), 2011-12-05 18:59:16]

Hi Randy,

This adds metrics for number of cookies, DB size, and the amount of time the
priority and initial load tasks wait in the queue (standard task profiler data
is still not available from the field).

Cheers,

Erik

[Randy Smith (Not in Mondays), 2011-12-05 22:18:07]

What's our current metric state?  The fact that the preload is still in this
code confused me some--did we remove the preload and it failed to do anything
good for us?

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
chrome/browser/net/sqlite_persistent_cookie_store.cc:345: 50);
Do the queue load histograms give us a lot more information than the built-in
profiler?  ("about:profiler")  Yes, we get a distribution rather than
average/max, but what we're really curious about getting the distribution for is
the amount of time we take doing our stuff, not the amount of time we're
waiting, I'd think?

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
chrome/browser/net/sqlite_persistent_cookie_store.cc:492: db_->Preload();
Didn't we nuke this?  Is there context I'm missing?

[erikwright (departed), 2011-12-06 00:07:08]

On 2011/12/05 22:18:07, rdsmith wrote:
> What's our current metric state?

See these issues:

http://crbug.com/105921
http://crbug.com/105918

Basically, it seems as though queue waiting is a major factor, so that is where
these metrics are aimed. If possible I'll commit this evening to get it in
before the branch.

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
File chrome/browser/net/sqlite_persistent_cookie_store.cc (right):

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
chrome/browser/net/sqlite_persistent_cookie_store.cc:345: 50);
AFAIK, task profiler data is not yet available from the field. You can only
visualize it on a running instance of Chromium, for a current run. The
information I found about shipping it back (slides from jar's talk) said the
work was only beginning.

So until then we have nothing.

On 2011/12/05 22:18:08, rdsmith wrote:
> Do the queue load histograms give us a lot more information than the built-in
> profiler?  ("about:profiler")  Yes, we get a distribution rather than
> average/max, but what we're really curious about getting the distribution for
is
> the amount of time we take doing our stuff, not the amount of time we're
> waiting, I'd think?

http://codereview.chromium.org/8802014/diff/1/chrome/browser/net/sqlite_persi...
chrome/browser/net/sqlite_persistent_cookie_store.cc:492: db_->Preload();
On 2011/12/05 22:18:08, rdsmith wrote:
> Didn't we nuke this?  Is there context I'm missing?

After uploading that CL I decided I would prefer to put the metrics in first and
then compare the before and after. My further research indicated to me that the
likely loss of time was substantially in queue waiting time.

So my intention is to commit the metrics, wait for data, then remove the preload
and compare.

[Randy Smith (Not in Mondays), 2011-12-06 16:22:09]

LGTM.  

If I could think of some way to easily instrument the DB thread to figure out
what we were waiting *on* I'd suggest doing that.  But I suspect waiting for
jar's work is probably the quickest way to get that data.

[commit-bot: I haz the power, 2011-12-06 16:23:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/erikwright@chromium.org/8802014/1

[erikwright (departed), 2011-12-06 16:24:12]

On 2011/12/06 16:22:09, rdsmith wrote:
> LGTM.  
> 
> If I could think of some way to easily instrument the DB thread to figure out
> what we were waiting *on* I'd suggest doing that.  But I suspect waiting for
> jar's work is probably the quickest way to get that data.

Agreed.

If I can confirm that, on all platforms, the primary problem is queue waiting, I
can at least look at all of the things running on the queue prior to these tasks
as suspects. At the moment, I have only identified this possible source of
problems on Linux.

[commit-bot: I haz the power, 2011-12-06 18:14:05]

Change committed as 113231