Changes

Jump to: navigation, search

Electrolysis/Multiple content processes

22 bytes removed, 12:40, 30 October 2017
replanning 1
= Overview =
After e10s is enabled for all users, the next step was to introduce multiple content processes. The goal is to bring out the most from the multi process architecture we introduced with e10s, gain performance where it's possible and minimize the impact of content process crashes. The challenge is to achieve this without sacrificing the advantage we currently have in memory usage compared to our competitors.
After e10s is enabled for The first step was to enable 4 content processes to all users, without non WebExtensions based add-ons. Before increasing the number of maximum processes the next step is to introduce multiple content processesfurther optimization. The goal is to bring out the most from the multi process architecture we introduced with e10s, gain performance where it's possible Memory consumption and minimize the impact of content process crashes. The challenge is to achieve this without sacrificing the advantage we currently have in startup time optimization, memory usage compared to our competitorsbalancing among content processes and user machine based customization based on performance statistics.
One explicit non-goal of this project is to nest content processes for e.g. iframes. There is work underway to do that in {{bug|1277066}} in parallel to this project.
= Roadmap Status ={| class="wikitable"|-! Version !! Status|-| 56 || Maximum 4 content processes for all e10s eligible users without any non WebExtension add-ons|-| 57 || Maximum 4 content processes for all e10s eligible users|-| 58 || No longer relying on the system add-on, prelaunching content process in the background|}== Memory management ==* [http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ Memory cost of a content process] - relatively high* [http://www.erahm.org/2016/02/12/are-they-slim-yet/ Memory usage of e10s compared to other browsers] - we're not the worst offender* [https://bugzilla.mozilla.org/show_bug.cgi?id=1381961 Enabled shared global for JSMs]== Content process startup time ==* [https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-central,1559690,1,1&series=mozilla-central,1559693,1,1&series=mozilla-central,1559696,1,1&series=mozilla-central,1559697,1,1&highlightedRevisions=8a3b8491838e ~300ms] - on most platforms (the OSX issue is investigated under: [https://bugzilla.mozilla.org/show_bug.cgi?id=1404309 bug 1404309])* The preallocated process manager is enabled from 58 = Current work =TBD
= Bug tracking =
== Priorities ==
* [https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=1371220813845618&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&status_whiteboard_type=anywordssubstrallwordssubstr&query_format=advanced&status_whiteboard=e10s-multi%3A%2B &bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED P1]* [https://bugzilla.mozilla.org/buglist.cgi?list_id=13845621&status_whiteboard_type=allwordssubstr&status_whiteboard=e10s-multi%3A%2B&priority=P2&list_id=13712208&resolution=---&status_whiteboard_typeresolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=anywordssubstrWORKSFORME&query_format=advanced&status_whiteboardbug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=e10s-multi%3A%2B REOPENED P2]* [https://bugzilla.mozilla.org/buglist.cgi?priority=P3&list_id=1371220813845618&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&status_whiteboard_type=anywordssubstrallwordssubstr&query_format=advanced&status_whiteboard=e10s-multi%3A%2B P3] &bug_status= Initial Rollout (completed 8/1/2017) UNCONFIRMED&bug_statusNEW&bug_status=ASSIGNED&bug_status= Release Criteria ==* '''Crash Rates''' need to be low enough that they have little, if any perceivable impact to the overall crash rates. See the crash rates starting with Firefox 54 Beta, [https://sql.telemetry.mozilla.org/queries/4355#8685 here]. * '''Performance''' metrics including memory-based metrics are in the [https://wiki.mozilla.org/Electrolysis/Multi_Release_Criteria release criteria wiki page]* '''We may need to activate e10s-multi based on physical RAM size''' depending how the number of content processes impacts such memory. We have a hypothesis for both cases (increased number of content process will either benefit systems with lower RAM or make things worse). == Release Plan ==* e10s-multi was enabled with 4 processes in Firefox 55 Nightly and currently beta experiments are being conducted in Firefox 54. Read more about the experiments, [https://wiki.mozilla.org/Electrolysis/Experiments#Beta_54 here]. == Memory management ==* [http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/ Memory cost of a content process] - relatively high* [http://www.erahm.org/2016/02/12/are-they-slim-yet/ Memory usage of e10s compared to other browsers] - we're not the worst offender* Extending Nuwa for all platform does not seem realistic, and since the most memory overhead comes from JS, we should address the problem at JS engine level first. Till Schneidereit suggested [https://bugzilla.mozilla.org/show_bug.cgi?id=876173 lazy cross-process memory sharing]. == Testing ==* [https://bugzilla.mozilla.org/show_bug.cgi?id=1312022 Currently for bc/dt tests we keep content processes alive to fight timeouts]* [https://bugzilla.mozilla.org/show_bug.cgi?id=1251963 Areas where additional testing is needed have to be identified.]* [https://bugzilla.mozilla.org/show_bug.cgi?id=1315042 Some tests were disabled, re-enabling them is high priority work currently] == Process startup time ==* [https://bugzilla.mozilla.org/show_bug.cgi?id=1336380 Improve content process startup timeREOPENED P3]
= Links =

Navigation menu