Closed Bug 1025048 Opened 6 years ago Closed 3 years ago
Investigate why 20% of requests for 29
.0 .1 complete updates come from versions where partials are available
I've been looking into update logs to understand what types of updates contribute to our overall CDN bandwidth, and to understand what effect serving partials to more users would have. I noticed a seemingly high percentage of users requesting complete updates that should be using partial updates. My data comes from hive with this query: insert overwrite local directory '/home/catlee/download_counts' select ds, ua_major, ua_minor, request_url, count(1) as c from v2_anonymous_logs where domain='download.mozilla.org' and ds >= '2014-05-01' and ds <= '2014-05-31' and request_url like '/?product=firefox-29.0.1%' and ua_family = 'Firefox' group by ds, ua_major, ua_minor, request_url; I then post-processed this data: - Use HEAD requests to figure out the size of each URL requested - Count how many requests and how many bytes were for complete/partial updates For 29.0.1 we have partial updates available to 27.0.1, 28.0, 29.0 users. So I also counted how many requests for partial updates came from users on those versions. Here's a summary of these results: Complete updates: 23,417,672,547,025,403b (58.12%) n=642,694,681 (41.65%) Partial updates: 16,871,014,243,483,169b (41.88%) n=900,354,424 (58.35%) Redundant completes: 4,781,919,026,860,840b (20.42%) n=130,647,218 (20.33%) This is showing that about 20% of requests for completes (by bytes or request count) were from versions where we had partial updates available. Breaking this down by platform shows that OSX builds are a bit more problematic in terms of % requesting completes that shouldn't (29.9%), but the overall impact of that is lower because OSX only makes up 1.6% of requests for complete updates. 98.1% of requests for complete updates are for windows.
As mentioned in last week's channel meeting - if it's possible to go back a couple of releases to see if this is approximately the same rate with them (or a recent regression in update request code) that would be useful data to have.
Chris, do we know if the requests for a complete update were alone, or followed by a download of a partial mar first? I wonder if some of the users ended-up with a broken mar file, which couldn't be installed, and therefore Firefox requested the full mar file. Something as what we also test with Mozmill.
(In reply to Henrik Skupin (:whimboo) [away 07/19 - 08/01] from comment #2) > Chris, do we know if the requests for a complete update were alone, or > followed by a download of a partial mar first? I wonder if some of the users > ended-up with a broken mar file, which couldn't be installed, and therefore > Firefox requested the full mar file. Something as what we also test with > Mozmill. No, it's pretty hard to tell from the data *why* the complete update was requested. I can only assume it attempted the partial and failed back to the complete for versions where we offered a partial, but perhaps there are other cases where it's doing this.
So we don't have IPs for those requests, which we could correlate? If users are falling back to full update mar files, we should have a request to the partial mar a couple of seconds/minutes earlier. Maybe that would help if possible?
While analyzing bug 1284915 using telemetry data it became apparent that at least for the majority of these cases that this is due to a networking error causing application update to try downloading the complete mar file. See bug 1284915 comment #55 for bugs to help address this.
Assignee: nobody → robert.strong.bugs
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.