Electrolysis/Release Criteria/Stability: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Link analysis)
(summarize)
Line 17: Line 17:
* content process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['content'] per 1000 hours of subsessionLength
* content process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['content'] per 1000 hours of subsessionLength
* plugin process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['plugin'] per 1000 hours of subsessionLength
* plugin process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['plugin'] per 1000 hours of subsessionLength
Other work items:
* dashboard for tracking: {{bug|1198842}} - Need a crash rate dashboard based on telemetry pings


Links:
Links:


Latest Spark analysis: [https://github.com/vitillo/e10s_analyses/blob/master/beta45-withoutaddons/e10s_crash_rate.ipynb e10s_crash_rate.ipynb] (reviewed by rvitillo)
Latest Spark analysis: [https://github.com/vitillo/e10s_analyses/blob/master/beta45-withoutaddons/e10s_crash_rate.ipynb e10s_crash_rate.ipynb] (reviewed by rvitillo)
SUMMARY: e10s is 33% worse in overall stability. That is entirely in the content process.

Revision as of 17:01, 25 February 2016

Why does this block? Stability is one of the foremost use cases for e10s. We must at least achieve parity in order to go live with e10s.

e10s can't regress crash stats or general stability.

  • a/b testing on beta should indicate that the rate of browser+content crashes is no larger than the non-e10s browser crash rate
  • a/b testing on beta should indicate that the rate of plugin crashes is no longer in e10s than non-e10s

RASCI:

  • Responsible: poiru
  • Accountable: bsmedberg
  • Supporting: Kairo, measurement/data teams
  • Consulted: release management
  • Informed: cpeterson, elan

Technical details:

  • chrome process crash rates will be measured with crash ping counts per 1000 hours of subsessionLength
  • content process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['content'] per 1000 hours of subsessionLength
  • plugin process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['plugin'] per 1000 hours of subsessionLength

Links:

Latest Spark analysis: e10s_crash_rate.ipynb (reviewed by rvitillo)

SUMMARY: e10s is 33% worse in overall stability. That is entirely in the content process.