E10s/Status/May26: Difference between revisions

From MozillaWiki
< E10s‎ | Status
Jump to navigation Jump to search
(Created page with "thumbnail|left<br> =e10s Update: '''May 16'''= ==Executive Summary== * '''e10s-multi was enabled as of Firefox 54 Beta 1 with 4 content processes'''. C...")
 
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Yellow-sm.jpg|thumbnail|left]]<br>
[[File:Green-sm.jpg|thumbnail|left]]<br>


=e10s Update: '''May 16'''=
=e10s Update: '''May 26'''=
==Executive Summary==
==Executive Summary==
* '''e10s-multi was enabled as of Firefox 54 Beta 1 with 4 content processes'''. Currently [https://sql.telemetry.mozilla.org/queries/4400/source#8797 26.2% of the 54 Beta population has e10s-Multi] enabled as compared to 21.15% last week. We are at a place in the project where we really don't have anything preventing the roll-out for Firefox 54 Release but we feel that we need to maintain an  'At Risk' profile until we have more time out in Beta. Though we have a great first pass at initial an telemetry performance data set, our sample sizes for Linux and Mac are low compared with Windows.We will remain yellow until we have more confidence we are meeting our  [https://wiki.mozilla.org/Electrolysis/Multi_Release_Criteria release criteria] at scale. Scroll below, to see more details.  
* '''Green means GO! For e10s-multi Firefox 54 Beta 1 with 4 content processes'''. Currently [https://sql.telemetry.mozilla.org/queries/4400/source#8797 26% of the 54 Beta population has e10s-Multi] enabled as compared to 21.15% the first week. After four weeks on beta, we have no major issues which would prevent us from shipping [https://wiki.mozilla.org/Electrolysis/Multi_Release_Criteria release criteria]. Scroll below, to see more details.
 
*'''The Release Plan is to activate e10s multi for 80% of our Release users without add-ons (leaving 20% of users without add-ons with single process). We are going to target 100% of that 80% on Day 1. If something goes awry, we can disable e10s multi with the System Add-On completely or, for a specific population exhibiting issues.  


* '''As of Firefox Release 53 (Mid May) [https://sql.telemetry.mozilla.org/queries/972#1659 53.96% of the total release population have Single-Process e10s]''' (as compared to 52.82 in Firefox 42 in early April). Single process e10s is active for non add-on users, and add-on that are web extensions or SDK add-ons actively marked compatible by the author.  
* '''As of Firefox Release 53 (Mid May) [https://sql.telemetry.mozilla.org/queries/972#1659 53.96% of the total release population have Single-Process e10s]''' (as compared to 52.82 in Firefox 42 in early April). Single process e10s is active for non add-on users, and add-on that are web extensions or SDK add-ons actively marked compatible by the author.  


* The plan is to continue convergence in time to ship A11y for Windows for Firefox 55; this project is designated at risk due to the challenges with instability. A go/no-go will need to happen no later than June 3rd.
* e10s and A11y for Windows has slipped from Firefox 55 to Firefox 56+ due to the challenges with instability.


==e10s-Multi Release Criteria==  
==e10s-Multi Release Criteria==  
*{{mok}} [https://sql.telemetry.mozilla.org/queries/4355#8687 Stability]. We have a tight correlation between single process and multi-process crashes which is good. We are concerned that the WebExtensions crashes in the content crash rate is higher than Non Web-Extensions. We thought we had a root cause with {{bug|1347984}} but it turns out it is not reproducible. Ben Miroglio has an action item to dissect the WebExtensions crashes so we can (a) detect which WebExtensions are crashier and (b) detect which crashes are most frequent. Otherwise, our stability criteria is being met but Multi so far.  
*{{mok}} [https://sql.telemetry.mozilla.org/queries/4355#8687 Stability]. We have a tight correlation between single process and multi-process crashes which is good. We decided that th WebExtensions crashes in the content crash rate is being higher than Non Web-Extensions was enough risk to not include WE extensions users in this initial roll-out for Firefox 54. There are a couple of fixes happening: a fix for initial signature which started this conversation {{bug|1347984}} has landed in beta and fixes found in {{bug|1358879}} will also help and shall ship in 55.
*{{mok}} [https://sql.telemetry.mozilla.org/queries/4400/source#8797 % of population shows us we'd like to increase the number of people we roll e10s-mutli out to in Beta 54] and this particular area was highlighted as 'At Risk' last week but can be considered 'On Track' as of this weeek. We have rolled out the beta Experiment to MPC=True Add-Ons to help increase our test population {{bug|1362493}}. One known risk item for MPC + Multi is the Lazy Tabs feature for Add-Ons isn't mutli compatible and we are working to see if it can be delayed {{bug|1363240}}.  
 
*{{mrisk}} [https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f2171cf2d000&newProject=try&newRevision=a038fa2d3c91&framework=1&showOnlyImportant=0 Performance numbers on Talos] shows us a regression in responsiveness for TP05 which is being addressed.
*{{mok}} [https://sql.telemetry.mozilla.org/queries/4400/source#8797 % of population shows us we'd like to increase the number of people we roll e10s-mutli out to in Beta 54] and this particular area was highlighted as 'At Risk' last week but can be considered 'On Track' as of this week. We have rolled out the beta Experiment to MPC=True Add-Ons to help increase our test population {{bug|1362493}}. One known risk item for MPC + Multi is the Lazy Tabs feature for Add-Ons isn't e0s mutli compatible and we are working to see if it can be delayed {{bug|1363240}}.  
 
*{{mok}} [https://metrics.mozilla.com/protected/bmiroglio/multi/e10sMulti_experiment.html Performance Telemetry] shows us that there is parity between 4 processes and single process e10s so far. This is considered to be meeting our release criteria thus far, though as mentioned above, we would like the sample size for Mac OS and Linux to increase a bit. A few areas we are keeping our eyes on include:
*{{mok}} [https://metrics.mozilla.com/protected/bmiroglio/multi/e10sMulti_experiment.html Performance Telemetry] shows us that there is parity between 4 processes and single process e10s so far. This is considered to be meeting our release criteria thus far, though as mentioned above, we would like the sample size for Mac OS and Linux to increase a bit. A few areas we are keeping our eyes on include:
**FX_TAB_SWITCH_SPINNER_VISIBLE_MS which has regressed slightly with multi, {{bug|1341008}} and {{bug|1342927}} are considered mitigations that have landed in Firefox 55. We don't think what we see in 54 is enough to block roll-out at this point.
 
*{{mok}} FX_TAB_SWITCH_SPINNER_VISIBLE_MS which has regressed slightly with multi, {{bug|1341008}} and {{bug|1342927}} are considered mitigations that have landed in Firefox 55. We don't think what we see in 54 is enough to block roll-out at this point.
** For tab switching metrics, it's worth noting that only about [https://mzl.la/2rmQhpD  3/4 of the beta population are using 3 or fewer tabs so we might find we have different results on release].  
** For tab switching metrics, it's worth noting that only about [https://mzl.la/2rmQhpD  3/4 of the beta population are using 3 or fewer tabs so we might find we have different results on release].  
*{{mok}} [https://wiki.mozilla.org/Electrolysis/Multi_Release_Criteria#Are_We_Slim_Yet_.28AWSY.29 Memory Usage] is considered to be on track. Our criteria is to be better than Chrome and [http://www.erahm.org/2017/05/15/firefox-memory-usage-with-multiple-content-processes/ Eric's latest findings] show us that we are. Gabor is adding telemetry so it is easy for us to see how many content processes are running when memory is being measured. When that lands, we will uplift to beta.
*{{mok}} [https://wiki.mozilla.org/Electrolysis/Multi_Release_Criteria#Are_We_Slim_Yet_.28AWSY.29 Memory Usage] is considered to be on track. Our criteria is to be better than Chrome and [http://www.erahm.org/2017/05/15/firefox-memory-usage-with-multiple-content-processes/ Eric's latest findings] show us that we are. Gabor is adding telemetry so it is easy for us to see how many content processes are running when memory is being measured. When that lands, we will uplift to beta.


==Upcoming Decisions and Milestones==  
==Upcoming Decisions and Milestones==  
* May 23 Compare MPC=data to our current Performance and Stability baseline
* [DONE] A go/no-go decision for doing an initial roll-out for Multi in Firefox 54 will happen no later than June 3rd.
* A go/no-go decision for doing an initial roll-out for Multi in Firefox 54 will happen no later than June 3rd.
* [DONE] May 23 Compare MPC=data to our current Performance and Stability baseline
* [DONE] [https://sql.telemetry.mozilla.org/queries/4400/source#8797 The % of Beta Users with e10s-Multi activated] in shows us that our initial experiment design doesn't activate E10s-Multi for as many users as we would like. 10% of the population is in the control group and 90% is in test, however, only 46% have e10s active and 21% which is has Multi enabled. We are currently activating e10s-Multi for users who either do not have add-ons installed or who are using WebExtensions only. Product's sentiment is that this approach is too conservative and is evaluating [https://wiki.mozilla.org/Firefox/AddOns/Status/current#Multiplecontent_Processes risk] vs. reward for expanding the experiment to include MPC=True Add-Ons for e10s Multi. This decision will be made by May 12th.
* [DONE] [https://sql.telemetry.mozilla.org/queries/4400/source#8797 The % of Beta Users with e10s-Multi activated] in shows us that our initial experiment design doesn't activate E10s-Multi for as many users as we would like. 10% of the population is in the control group and 90% is in test, however, only 46% have e10s active and 21% which is has Multi enabled. We are currently activating e10s-Multi for users who either do not have add-ons installed or who are using WebExtensions only. Product's sentiment is that this approach is too conservative and is evaluating [https://wiki.mozilla.org/Firefox/AddOns/Status/current#Multiplecontent_Processes risk] vs. reward for expanding the experiment to include MPC=True Add-Ons for e10s Multi. This decision will be made by May 12th.
* [DONE] We should have complete data for our release criteria by EOD May 10
* [DONE] We should have complete data for our release criteria by EOD May 10


==Engineering Status + Schedule==  
==Engineering Status + Schedule==  
* Engineering highlights include recently landed {{Bug|1341008}} Use the preallocated process manager by default which Preloads a content process in the background when the browser is idle and using that the next time we need one which will greatly improve load time.  
* Engineering highlights include combing through the back log and preparing for planning. Patch volume is down because of the palce we are in the project; we are finished with convergence and keeping an eye on incoming issues. We are currently working to land {{bug|1364849}}. Next up, we will be planning for the future which will happen during the San Francisco work week.
* Top issues we are investigating include:
*{{bug|1363240}} Content process limit specified by dom.ipc.processCount is not respected in some circumstances

Latest revision as of 17:46, 26 May 2017

Green-sm.jpg


e10s Update: May 26

Executive Summary

  • Green means GO! For e10s-multi Firefox 54 Beta 1 with 4 content processes. Currently 26% of the 54 Beta population has e10s-Multi enabled as compared to 21.15% the first week. After four weeks on beta, we have no major issues which would prevent us from shipping release criteria. Scroll below, to see more details.
  • The Release Plan is to activate e10s multi for 80% of our Release users without add-ons (leaving 20% of users without add-ons with single process). We are going to target 100% of that 80% on Day 1. If something goes awry, we can disable e10s multi with the System Add-On completely or, for a specific population exhibiting issues.
  • e10s and A11y for Windows has slipped from Firefox 55 to Firefox 56+ due to the challenges with instability.

e10s-Multi Release Criteria

  • [ON TRACK] Stability. We have a tight correlation between single process and multi-process crashes which is good. We decided that th WebExtensions crashes in the content crash rate is being higher than Non Web-Extensions was enough risk to not include WE extensions users in this initial roll-out for Firefox 54. There are a couple of fixes happening: a fix for initial signature which started this conversation bug 1347984 has landed in beta and fixes found in bug 1358879 will also help and shall ship in 55.
  • [ON TRACK] Performance Telemetry shows us that there is parity between 4 processes and single process e10s so far. This is considered to be meeting our release criteria thus far, though as mentioned above, we would like the sample size for Mac OS and Linux to increase a bit. A few areas we are keeping our eyes on include:
  • [ON TRACK] Memory Usage is considered to be on track. Our criteria is to be better than Chrome and Eric's latest findings show us that we are. Gabor is adding telemetry so it is easy for us to see how many content processes are running when memory is being measured. When that lands, we will uplift to beta.

Upcoming Decisions and Milestones

  • [DONE] A go/no-go decision for doing an initial roll-out for Multi in Firefox 54 will happen no later than June 3rd.
  • [DONE] May 23 Compare MPC=data to our current Performance and Stability baseline
  • [DONE] The % of Beta Users with e10s-Multi activated in shows us that our initial experiment design doesn't activate E10s-Multi for as many users as we would like. 10% of the population is in the control group and 90% is in test, however, only 46% have e10s active and 21% which is has Multi enabled. We are currently activating e10s-Multi for users who either do not have add-ons installed or who are using WebExtensions only. Product's sentiment is that this approach is too conservative and is evaluating risk vs. reward for expanding the experiment to include MPC=True Add-Ons for e10s Multi. This decision will be made by May 12th.
  • [DONE] We should have complete data for our release criteria by EOD May 10

Engineering Status + Schedule

  • Engineering highlights include combing through the back log and preparing for planning. Patch volume is down because of the palce we are in the project; we are finished with convergence and keeping an eye on incoming issues. We are currently working to land bug 1364849. Next up, we will be planning for the future which will happen during the San Francisco work week.