While researching this “better display for compute hours per checkin” post , I noticed that we now “only” consume 207 compute hours of builds and tests per checkin. A month ago, we handled 254 compute-hours-per-checkin, so this is a reduction of 47 compute-hours-per-checkin.
No “magic silver bullet” here, just people quietly doing detailed unglamorous work finding, confirming and turning off no-longer-needed-jobs. For me, the biggest gains were turning off “talos dirtypaint” and “talos rafx” across all desktop OS, a range of b2g device builds, all Android no-ionmonkey builds and tests, and a range of Android armv6, armv7 builds and tests. At Mozilla’s volume-of-checkins, saving 47 hours-per-checkin is a big big deal.
This reduced our overall load by 23%. Or put another way – this work gave us 23% extra “spare” capacity to better handle the remaining builds and tests that people *do* care about.
Great, great work by sheriffs and RelEng. Thank. You.
How many hours of builds and tests do we run per commit?
- 207 compute hours = ~8.6 compute *days* (nov2013)
- 254 compute hours = ~10.5 compute *days* (sep2013)
- 137 compute hours = ~5.7 compute *days* (aug2012)
- 110 compute hours = ~4.6 compute *days*(jan2012)
- ~40 compute hours = ~1.6 compute *days*(2009)
There’s still more goodness to come, as even more jobs continue to be trimmed; the curious can follow bug#784681. Of course, if you see any build/test here which is no longer needed, or is perma-failing-and-hidden on tbpl.mozilla.org, please file a bug linked to bug#784681 and we’ll investigate/disable/fix as appropriate.
3 thoughts on “Now saving 47 compute hours per checkin!”
John O’Duinn: Now saving 47 compute hours per checkin! – http://t.co/TGIxT7vS5Z #mozilla #mozillians mozilla
Good work guys. Great to see these graphs trend in a happy direction
[…] Overall this month was quieter then usual. I’d guess that this was caused by a combination of fatigue after the September B2G workweek, the October stabilization+lockdown period for B2Gv1.2, and Canadian Thanksgiving. Data for November is already higher, back towards more typical numbers. A big win was turning off obsolete builds and tests which reduced our load by 20%. […]
You must log in to post a comment.