Remove the majority of the high-traffic Net.Async* histograms.

Remove the majority of the high-traffic Net.AsyncResourceHandler histograms.

Specifically:
Net.AsyncResourceHandler_PendingDataCount
Net.AsyncResourceHandler_PendingDataCount_WhenFull
Net.AsyncResourceHandler_SharedIOBuffer_Alloc
Net.AsyncResourceHandler_SharedIOBuffer_Used
Net.AsyncResourceHandler_SharedIOBuffer_UsedPercentage

Are any of these still looked at? They are still all unowned.

I've left Net.AsyncResourceHandler_RedirectHopTime since that is specifically owned by bnc@. Is this histogram still useful?

BUG=469288
Committed: https://crrev.com/38e1bbcec917f2a795046185f50406164c89b369
Cr-Commit-Position: refs/heads/master@{#322011}

[rkaplow, 2015-03-20 21:36:38]

rkaplow@chromium.org changed reviewers:
+ bnc@chromium.org, isherman@chromium.org, mmenke@chromium.org

[mmenke, 2015-03-20 21:39:04]

This LGTM, assuming bnc has no objections.  I'm unfamiliar with them, and if
anyone really wants them, can add them back and take ownership.

[Bence, 2015-03-20 21:44:26]

On 2015/03/20 21:39:04, mmenke wrote:
> This LGTM, assuming bnc has no objections.  I'm unfamiliar with them, and if
> anyone really wants them, can add them back and take ownership.

LGTM, I believe they can go.

As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
https://codereview.chromium.org/555913002, but then never looked at the numbers.
 It is potentially useful for assessing how long the AsyncResourceHandler
browser->render->browser hop takes.

[Ilya Sherman, 2015-03-20 21:45:03]

histograms.xml lgtm

[rkaplow, 2015-03-20 21:48:07]

On 2015/03/20 21:44:26, Bence wrote:
> On 2015/03/20 21:39:04, mmenke wrote:
> > This LGTM, assuming bnc has no objections.  I'm unfamiliar with them, and if
> > anyone really wants them, can add them back and take ownership.
> 
> LGTM, I believe they can go.
> 
> As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> https://codereview.chromium.org/555913002, but then never looked at the
numbers.
>  It is potentially useful for assessing how long the AsyncResourceHandler
> browser->render->browser hop takes.

Do you know if anyone has looked at it or will in the next few months? This is
one of our most expensive histograms and I would prefer we only leave it if this
is a metric we need to continuously keep our eyes on.

[rkaplow, 2015-03-20 21:50:31]

On 2015/03/20 21:48:07, rkaplow wrote:
> On 2015/03/20 21:44:26, Bence wrote:
> > On 2015/03/20 21:39:04, mmenke wrote:
> > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with them, and
if
> > > anyone really wants them, can add them back and take ownership.
> > 
> > LGTM, I believe they can go.
> > 
> > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> > https://codereview.chromium.org/555913002, but then never looked at the
> numbers.
> >  It is potentially useful for assessing how long the AsyncResourceHandler
> > browser->render->browser hop takes.
> 
> Do you know if anyone has looked at it or will in the next few months? This is
> one of our most expensive histograms and I would prefer we only leave it if
this
> is a metric we need to continuously keep our eyes on.

Sorry, relooking at it and RedirectHopTime isn't as expensive as the other Async
metrics - it's not quite as bad, but it is still high traffic.
So I feel slightly less strongly about removing, so up to you.

[mmenke, 2015-03-20 21:52:13]

On 2015/03/20 21:50:31, rkaplow wrote:
> On 2015/03/20 21:48:07, rkaplow wrote:
> > On 2015/03/20 21:44:26, Bence wrote:
> > > On 2015/03/20 21:39:04, mmenke wrote:
> > > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with them,
and
> if
> > > > anyone really wants them, can add them back and take ownership.
> > > 
> > > LGTM, I believe they can go.
> > > 
> > > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> > > https://codereview.chromium.org/555913002, but then never looked at the
> > numbers.
> > >  It is potentially useful for assessing how long the AsyncResourceHandler
> > > browser->render->browser hop takes.
> > 
> > Do you know if anyone has looked at it or will in the next few months? This
is
> > one of our most expensive histograms and I would prefer we only leave it if
> this
> > is a metric we need to continuously keep our eyes on.
> 
> Sorry, relooking at it and RedirectHopTime isn't as expensive as the other
Async
> metrics - it's not quite as bad, but it is still high traffic.
> So I feel slightly less strongly about removing, so up to you.

rkaplow:  Way beyond the scope of this CL, of course, but has there been any
thought given to supporting subsampling histograms in cases like this?  Could
imagine just recording data 1 in 100 or 1000 times and still getting useful
numbers.

[rkaplow, 2015-03-20 21:59:33]

On 2015/03/20 21:52:13, mmenke wrote:
> On 2015/03/20 21:50:31, rkaplow wrote:
> > On 2015/03/20 21:48:07, rkaplow wrote:
> > > On 2015/03/20 21:44:26, Bence wrote:
> > > > On 2015/03/20 21:39:04, mmenke wrote:
> > > > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with them,
> and
> > if
> > > > > anyone really wants them, can add them back and take ownership.
> > > > 
> > > > LGTM, I believe they can go.
> > > > 
> > > > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> > > > https://codereview.chromium.org/555913002, but then never looked at the
> > > numbers.
> > > >  It is potentially useful for assessing how long the
AsyncResourceHandler
> > > > browser->render->browser hop takes.
> > > 
> > > Do you know if anyone has looked at it or will in the next few months?
This
> is
> > > one of our most expensive histograms and I would prefer we only leave it
if
> > this
> > > is a metric we need to continuously keep our eyes on.
> > 
> > Sorry, relooking at it and RedirectHopTime isn't as expensive as the other
> Async
> > metrics - it's not quite as bad, but it is still high traffic.
> > So I feel slightly less strongly about removing, so up to you.
> 
> rkaplow:  Way beyond the scope of this CL, of course, but has there been any
> thought given to supporting subsampling histograms in cases like this?  Could
> imagine just recording data 1 in 100 or 1000 times and still getting useful
> numbers.

It's a good point. It has come up before but nothing concrete has really
emerged.

There's been quite little work done on pruning histograms done in general, I'm
just doing a bit of the lowest hanging fruit (high usage, unowned/unused). We've
never really had a huge need for sampling so we never looked into it seriously.
That being said, I'm only looking to cut out histograms that aren't being looked
at at all. If we got to the point where that wasn't enough, sampling is a good
next step.

[cbentzel, 2015-03-23 12:37:53]

On 2015/03/20 21:59:33, rkaplow wrote:
> On 2015/03/20 21:52:13, mmenke wrote:
> > On 2015/03/20 21:50:31, rkaplow wrote:
> > > On 2015/03/20 21:48:07, rkaplow wrote:
> > > > On 2015/03/20 21:44:26, Bence wrote:
> > > > > On 2015/03/20 21:39:04, mmenke wrote:
> > > > > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with
them,
> > and
> > > if
> > > > > > anyone really wants them, can add them back and take ownership.
> > > > > 
> > > > > LGTM, I believe they can go.
> > > > > 
> > > > > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> > > > > https://codereview.chromium.org/555913002, but then never looked at
the
> > > > numbers.
> > > > >  It is potentially useful for assessing how long the
> AsyncResourceHandler
> > > > > browser->render->browser hop takes.
> > > > 
> > > > Do you know if anyone has looked at it or will in the next few months?
> This
> > is
> > > > one of our most expensive histograms and I would prefer we only leave it
> if
> > > this
> > > > is a metric we need to continuously keep our eyes on.
> > > 
> > > Sorry, relooking at it and RedirectHopTime isn't as expensive as the other
> > Async
> > > metrics - it's not quite as bad, but it is still high traffic.
> > > So I feel slightly less strongly about removing, so up to you.
> > 
> > rkaplow:  Way beyond the scope of this CL, of course, but has there been any
> > thought given to supporting subsampling histograms in cases like this? 
Could
> > imagine just recording data 1 in 100 or 1000 times and still getting useful
> > numbers.
> 
> It's a good point. It has come up before but nothing concrete has really
> emerged.
> 
> There's been quite little work done on pruning histograms done in general, I'm
> just doing a bit of the lowest hanging fruit (high usage, unowned/unused).
We've
> never really had a huge need for sampling so we never looked into it
seriously.
> That being said, I'm only looking to cut out histograms that aren't being
looked
> at at all. If we got to the point where that wasn't enough, sampling is a good
> next step.

I'm OK with removing this histogram. It actually turns out to have pretty
interesting results, but we can capture the summary statistics and stop
collecting data.

[rkaplow, 2015-03-23 14:46:10]

On 2015/03/23 12:37:53, cbentzel wrote:
> On 2015/03/20 21:59:33, rkaplow wrote:
> > On 2015/03/20 21:52:13, mmenke wrote:
> > > On 2015/03/20 21:50:31, rkaplow wrote:
> > > > On 2015/03/20 21:48:07, rkaplow wrote:
> > > > > On 2015/03/20 21:44:26, Bence wrote:
> > > > > > On 2015/03/20 21:39:04, mmenke wrote:
> > > > > > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with
> them,
> > > and
> > > > if
> > > > > > > anyone really wants them, can add them back and take ownership.
> > > > > > 
> > > > > > LGTM, I believe they can go.
> > > > > > 
> > > > > > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it in
> > > > > > https://codereview.chromium.org/555913002, but then never looked at
> the
> > > > > numbers.
> > > > > >  It is potentially useful for assessing how long the
> > AsyncResourceHandler
> > > > > > browser->render->browser hop takes.
> > > > > 
> > > > > Do you know if anyone has looked at it or will in the next few months?
> > This
> > > is
> > > > > one of our most expensive histograms and I would prefer we only leave
it
> > if
> > > > this
> > > > > is a metric we need to continuously keep our eyes on.
> > > > 
> > > > Sorry, relooking at it and RedirectHopTime isn't as expensive as the
other
> > > Async
> > > > metrics - it's not quite as bad, but it is still high traffic.
> > > > So I feel slightly less strongly about removing, so up to you.
> > > 
> > > rkaplow:  Way beyond the scope of this CL, of course, but has there been
any
> > > thought given to supporting subsampling histograms in cases like this? 
> Could
> > > imagine just recording data 1 in 100 or 1000 times and still getting
useful
> > > numbers.
> > 
> > It's a good point. It has come up before but nothing concrete has really
> > emerged.
> > 
> > There's been quite little work done on pruning histograms done in general,
I'm
> > just doing a bit of the lowest hanging fruit (high usage, unowned/unused).
> We've
> > never really had a huge need for sampling so we never looked into it
> seriously.
> > That being said, I'm only looking to cut out histograms that aren't being
> looked
> > at at all. If we got to the point where that wasn't enough, sampling is a
good
> > next step.
> 
> I'm OK with removing this histogram. It actually turns out to have pretty
> interesting results, but we can capture the summary statistics and stop
> collecting data.

To clarify, are you referring to Net.AsyncResourceHandler_RedirectHopTime or the
other histograms I am removing here?

[rkaplow, 2015-03-24 14:49:07]

On 2015/03/23 14:46:10, rkaplow wrote:
> On 2015/03/23 12:37:53, cbentzel wrote:
> > On 2015/03/20 21:59:33, rkaplow wrote:
> > > On 2015/03/20 21:52:13, mmenke wrote:
> > > > On 2015/03/20 21:50:31, rkaplow wrote:
> > > > > On 2015/03/20 21:48:07, rkaplow wrote:
> > > > > > On 2015/03/20 21:44:26, Bence wrote:
> > > > > > > On 2015/03/20 21:39:04, mmenke wrote:
> > > > > > > > This LGTM, assuming bnc has no objections.  I'm unfamiliar with
> > them,
> > > > and
> > > > > if
> > > > > > > > anyone really wants them, can add them back and take ownership.
> > > > > > > 
> > > > > > > LGTM, I believe they can go.
> > > > > > > 
> > > > > > > As for Net.AsyncResourceHandler_RedirectHopTime, I introduced it
in
> > > > > > > https://codereview.chromium.org/555913002, but then never looked
at
> > the
> > > > > > numbers.
> > > > > > >  It is potentially useful for assessing how long the
> > > AsyncResourceHandler
> > > > > > > browser->render->browser hop takes.
> > > > > > 
> > > > > > Do you know if anyone has looked at it or will in the next few
months?
> > > This
> > > > is
> > > > > > one of our most expensive histograms and I would prefer we only
leave
> it
> > > if
> > > > > this
> > > > > > is a metric we need to continuously keep our eyes on.
> > > > > 
> > > > > Sorry, relooking at it and RedirectHopTime isn't as expensive as the
> other
> > > > Async
> > > > > metrics - it's not quite as bad, but it is still high traffic.
> > > > > So I feel slightly less strongly about removing, so up to you.
> > > > 
> > > > rkaplow:  Way beyond the scope of this CL, of course, but has there been
> any
> > > > thought given to supporting subsampling histograms in cases like this? 
> > Could
> > > > imagine just recording data 1 in 100 or 1000 times and still getting
> useful
> > > > numbers.
> > > 
> > > It's a good point. It has come up before but nothing concrete has really
> > > emerged.
> > > 
> > > There's been quite little work done on pruning histograms done in general,
> I'm
> > > just doing a bit of the lowest hanging fruit (high usage, unowned/unused).
> > We've
> > > never really had a huge need for sampling so we never looked into it
> > seriously.
> > > That being said, I'm only looking to cut out histograms that aren't being
> > looked
> > > at at all. If we got to the point where that wasn't enough, sampling is a
> good
> > > next step.
> > 
> > I'm OK with removing this histogram. It actually turns out to have pretty
> > interesting results, but we can capture the summary statistics and stop
> > collecting data.
> 
> To clarify, are you referring to Net.AsyncResourceHandler_RedirectHopTime or
the
> other histograms I am removing here?

I didn't get a response about the Net.AsyncResourceHandler_RedirectHopTime
histogram which wasn't the target of this CL, so I will submit.
I do suggest removing it if it isn't being used.

[rkaplow, 2015-03-24 14:49:13]

The CQ bit was checked by rkaplow@chromium.org

[commit-bot: I haz the power, 2015-03-24 14:49:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1025813002/1

[commit-bot: I haz the power, 2015-03-24 16:15:29]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-24 16:16:31]

Patchset 1 (id:??) landed as
https://crrev.com/38e1bbcec917f2a795046185f50406164c89b369
Cr-Commit-Position: refs/heads/master@{#322011}

[Bence, 2015-04-01 11:47:35]

FYI Net.AsyncResourceHandler_RedirectHopTime has been removed at
https://crrev.com/1050673002.  Thanks for bringing it up.