[Downloads] Retry renames after transient failures.

content/browser/download/download_stats.cc

 // Copyright (c) 2012 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 "content/browser/download/download_stats.h"
 
 #include "base/metrics/histogram.h"
 #include "base/metrics/sparse_histogram.h"
 #include "base/strings/string_util.h"
 #include "content/browser/download/download_resource_handler.h"
@@ skipping 593 matching lines @@
   UMA_HISTOGRAM_CUSTOM_COUNTS(
       "Download.BandwidthOverallBytesPerSecond",
       (1000 * length / elapsed_time_ms), 1, 50000000, 50);
   UMA_HISTOGRAM_CUSTOM_COUNTS(
       "Download.BandwidthDiskBytesPerSecond",
       (1000 * length / disk_write_time_ms), 1, 50000000, 50);
   UMA_HISTOGRAM_COUNTS_100("Download.DiskBandwidthUsedPercentage",
                            disk_write_time_ms * 100 / elapsed_time_ms);
 }
 
+void RecordDownloadFileRenameResultAfterRetry(
+    base::TimeDelta time_since_first_failure,
+    DownloadInterruptReason interrupt_reason) {
+  if (interrupt_reason == DOWNLOAD_INTERRUPT_REASON_NONE) {
+    UMA_HISTOGRAM_TIMES("Download.TimeToRenameSuccessAfterInitialFailure",
+                        time_since_first_failure);
+  } else {
+    UMA_HISTOGRAM_TIMES("Download.TimeToRenameFailureAfterInitialFailure",
+                        time_since_first_failure);
+  }

[Randy Smith (Not in Mondays), 2014/06/11 18:07:29]

I may be a missing a corner case of the math, but at first glance I feel like
these UMA don't give us everything we need to evaluate what's going on;
specifically, I don't think they tell us how often the initial rename failed. 
We'll only get success results for renames that don't fall off the end of the
retry count, so we won't be able to tell the difference between (e.g.) some 2x
retries and no never-succeeded, and many never succeeded and some 1x retries.  

[asanka, 2014/06/12 20:02:37]

This stat is recorded whenever we retry a rename regardless of the final
outcome. The final outcome determines which histogram is updated. So, some 2x
retries and no never-succeeded:

Download.TimeToRenameSuccessAfterInitialFailure
Time(ms) \ Frequency:
000 :
200 :
300 : 
400 : ####
500 : ##
600 : 
700 :
800 :

Download.TimeToRenameFailureAfterInitialFailure
Time(ms) \ Frequency:
000 :
200 :
300 :
400 :
500 :
600 :
700 :
800 :

Many never succeeded and some 1x retries:

Download.TimeToRenameSuccessAfterInitialFailure
Time(ms) \ Frequency:
000 :
200 : ####
300 : #
400 : 
500 : 
600 : 
700 :
800 :

Download.TimeToRenameFailureAfterInitialFailure
Time(ms) \ Frequency:
000 :
200 :
300 :
400 :
500 :
600 :
700 :
800 : #######################################

+}
+
 void RecordSavePackageEvent(SavePackageEvent event) {
   UMA_HISTOGRAM_ENUMERATION("Download.SavePackage",
                             event,
                             SAVE_PACKAGE_LAST_ENTRY);
 }
 
 void RecordOriginStateOnResumption(bool is_partial,
                                    int state) {
   if (is_partial)
     UMA_HISTOGRAM_ENUMERATION("Download.OriginStateOnPartialResumption", state,
                               ORIGIN_STATE_ON_RESUMPTION_MAX);
   else
     UMA_HISTOGRAM_ENUMERATION("Download.OriginStateOnFullResumption", state,
                               ORIGIN_STATE_ON_RESUMPTION_MAX);
 }
 
 }  // namespace content