Open Bug 1559064 Opened 5 years ago Updated 2 years ago

0.29 - 0.31% installer size (osx-shippable) regression on push d8e5effba596ee138920231adb9a552fccf2b310 (Mon June 10 2019)

Categories

(Firefox :: Installer, defect, P3)

Unspecified
macOS
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox68 --- unaffected
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- fix-optional

People

(Reporter: igoldan, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: perf-alert, regression)

We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=35bf2fd7dc3bb1376a942180a12c30015a4a04af&tochange=d8e5effba596ee138920231adb9a552fccf2b310

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

+200KBytes installer size osx-shippable opt gcp nightly 78,437,121.75 -> 78,682,139.83
+200Kybtes installer size osx-shippable opt nightly 78,453,869.17 -> 78,682,032.08

You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=21393

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Automated_Performance_Testing_and_Sheriffing/Build_Metrics

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Component: General → Installer
Product: Testing → Firefox

This is a weird binary increase, which was caused by the ffxbld bot.
RyanVM, do you know why this happened?

Flags: needinfo?(ryanvm)

Looks like that update bumped services/settings/dumps/security-state/intermediates.json from 1.21MB to 1.79MB, which I guess would be a plausible explanation since this is a file which gets shipped to users.

That said, bug 1541841 comment 1 makes it sound like this file isn't expected to grow very fast, so I'm not sure what caused it to increase in size so much with this update. Maybe JC can shed some light on that (or redirect to someone who would)?

Flags: needinfo?(ryanvm) → needinfo?(jjones)

I haven't had time to analyze the state of the CCADB between Feb and this month yet. That said, some amount of this change would be addition of two more SHA256 hashes to each of the entries of the dataset - a delta that wouldn't be repeated.

In Bug 1552304 we added two fields, one for a Base64-encoded X.500 Subject (subjectDN), and one for a Base64-encoded SHA256 digest (derHash), in order to support Bug 1552310.

We have 2279 entries. We added these two fields, where derHash is consistently 44 bytes, and subjectDN averages 163 bytes.

Taking the actual sum of all subjectDNs, that's 372,696 bytes added, plus the 44 * 2279 = 100,276 bytes, so that accounts for ~500kB, which is basically the delta.

Dana and I resolved Bug 1552310 via this additional data, and I don't see any reason we'd expand this dataset further.

So basically, this isn't unexpected growth, it's just uncommunicated growth.

If the team would like, we think we could file a bug to empty out the ASCII subject field, as subjectDN could (if it hasn't already) replace it.

Flags: needinfo?(jjones)

Any more concerns here?

Flags: needinfo?(igoldan)

Florin, maybe you can comment while Ionut is on PTO?

Flags: needinfo?(fstrugariu)

:jcj I understand the change and have no concerns here.

If you can please go ahead and log the bug to empty out the ASCII subject field, as subjectDN

Flags: needinfo?(jjones)
Flags: needinfo?(igoldan)
Flags: needinfo?(fstrugariu)

Filed Bug 1565282.

Flags: needinfo?(jjones)
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.