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.

RASCI

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

Metrics

chrome+content process crash rates

A/B testing on beta should indicate that the rate of browser+content crashes is no larger than the non-e10s browser crash rate. 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.

Latest Spark analysis, 46 experiment #1: e10s-stability-analysis.ipynb (reviewed by rvitillo)

SUMMARY: e10s is now 62% worse in overall stability (chrome+content crashes). 17.1 crashes per 1000 usage hours for non-e10s, 27.8 for e10s. That regression is entirely in the content process: chrome-process stability has improved dramatically from 15.2 to 7.93.

New UT/e10s Crash Reporting proposal

plugin process crash rates

A/B testing on beta should indicate that the rate of plugin crashes is no longer in e10s than non-e10s. Plugin process crash rates will be measured with SUBPROCESS_CRASHES_WITH_DUMP['plugin'] per 1000 hours of subsessionLength.

e10s is worse: crash rate of 8.1 for non-e10s and 12.1 for e10s.

Bugs

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);