Add a field trial to delay all resource requests by thread hops.

chrome/browser/renderer_host/thread_hop_resource_throttle.cc

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/renderer_host/thread_hop_resource_throttle.h"
+
+#include "base/bind.h"
+#include "base/bind_helpers.h"
+#include "base/location.h"
+#include "base/metrics/field_trial.h"
+#include "base/metrics/histogram_macros.h"
+#include "base/strings/string_util.h"
+#include "base/time/time.h"
+#include "content/public/browser/browser_thread.h"
+#include "content/public/browser/resource_controller.h"
+
+ThreadHopResourceThrottle::ThreadHopResourceThrottle() : weak_factory_(this) {}
+
+ThreadHopResourceThrottle::~ThreadHopResourceThrottle() {}
+
+bool ThreadHopResourceThrottle::IsEnabled() {
+  const std::string group_name =
+      base::FieldTrialList::FindFullName("ThreadHopResourceThrottle");
+  return base::StartsWith(group_name, "Enabled", base::CompareCase::SENSITIVE);
+}
+
+void ThreadHopResourceThrottle::WillStartRequest(bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+void ThreadHopResourceThrottle::WillRedirectRequest(
+    const net::RedirectInfo& redirect_info,
+    bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+void ThreadHopResourceThrottle::WillProcessResponse(bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+const char* ThreadHopResourceThrottle::GetNameForLogging() const {
+  return "ThreadHopResourceThrottle";
+}
+
+void ThreadHopResourceThrottle::ResumeAfterThreadHop() {
+  content::BrowserThread::PostTaskAndReply(
+      content::BrowserThread::UI, FROM_HERE, base::Bind(&base::DoNothing),
+      base::Bind(&ThreadHopResourceThrottle::Resume, weak_factory_.GetWeakPtr(),
+                 base::TimeTicks::Now()));
+}
+
+void ThreadHopResourceThrottle::Resume(const base::TimeTicks& time) {
+  UMA_HISTOGRAM_CUSTOM_TIMES("Net.ThreadHopResourceThrottleTime",
+                             base::TimeTicks::Now() - time, base::TimeDelta(),
+                             base::TimeDelta::FromMilliseconds(100), 100);

[Alexei Svitkine (slow), 2015/10/02 16:42:54]

Is there a reason you picked these parameters?

Having 100ms as the max for a timing macro seems like it would result a lot of
samples in the overflow bucket. Also, why 100 buckets and not e.g. 50 that is
more typical?

For example, why not just use UMA_HISTOGRAM_TIMES()?

[davidben, 2015/10/02 17:19:42]

I picked 100 because it looked like others did this too, though it seems I
looked at exactly the wrong ones and 50's more common. :-) I'll switch to that.

UMA_HISTOGRAM_TIMES goes up to 10 seconds and I would be surprised if it goes up
anywhere near that high. It's just measuring a pair of thread hops. 10 / 50 is
0.2 seconds which is probably already high enough that I'd want to avoid the
thread hop. Or am I completely misunderstanding what the number of buckets means
and their distribution?

Is UMA_HISTOGRAMS_TIMES still what I want for this kind of metric?

[Alexei Svitkine (slow), 2015/10/02 17:30:43]

These macros provide a exponential distribution. So while you do have a max of
10s, the bucket sizes near there will be much higher and you'll get more
granularity at the lower values. For example, here's the distribution from that
macro for another histogram:

https://uma.googleplex.com/histograms/?dayCount=1&endDate=10-01-2015&version=...

Is the granularity sufficient? If so, then I think it's fine to use it.
Otherwise, up to you if you want something shorter. I'm actually ok if we want
to add an UMA_HISTOGRAM_SHORT_TIMES().

[davidben, 2015/10/02 17:39:39]

Gotcha. UMA_HISTOGRAM_TIMES it is then!

+  controller()->Resume();
+}