Electrolysis/Multiple content processes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(current work + future plans)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Goals ==
After e10s is enabled for all users, the next step is 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.


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.
= 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.


== What to expect ==
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 further optimization. Memory consumption and content process startup time optimization, memory balancing among content processes and user machine based customization based on performance statistics.  
First, we will enable 2 content processes and fix correctness bugs in the DOM and frontend components. Then we will start ramping up the number of content processes while optimizing memory use in order to avoid using too much memory overall. Once we have that we can think about advanced process models, sandboxing and how can we get the most out of multiple content processes.


== Roadmap ==
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.
=== M1[Nightly {{bug|1303113}}]: enable 2 content processes on nightly (Done) ===
Apart a few corner cases 2 content processes are fairly stable for everyday usage. Our hope is that by enabling 2 content processes on nightly despite a few known issues that will be time consuming to fix (session storage / shared workers) we will get better bug reports early.
* Ignore memory footprint.
* Fix crash report in background tabs {{bug|1241459}}
* '''Known issues that will block riding the train but will not block enabling 2 content processes on nightly:'''
** Service/Shared workers should run in their own process: {{bug|1231208}}
** Some test will need some refactoring: {{bug|1301015}} but for now we will force them to use single content process: {{bug|1301340}}
 
=== M2[Aurora {{bug|1304546}}]: Correctness, Measuring Performance and Memory, and Scaling to 4 Processes (Done)===
* Measure the memory footprint of content processes
* Measure startup of content process ({{bug|1336389}}, {{bug|1304790}})
* Start optimizing memory use
* Prepare to go beyond 2 content processes (aiming for 4 initially {{bug|1336398}}).
* Service Workers in it's own content process <== we are not going to block on a full implementation of this.  
* AWSY ({{bug|1272113}})
 
=== M3[Beta {{bug|1304547}}]: Optimization and Preparing for Release ===
* Memory optimization
* Performance optimization
* Solidifying Automated tests (working with module owners)
* General Convergence; focusing on quality
 
==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 is currently enabled with 4 processes in Firefox 55 Nightly
* We plan on uplifting as many changes as possible to Firefox 54 Aurora and enabling 4 processes
* If everything looks good, we will conduct an experiment in Beta 1


= 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 ==
== 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/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
* [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].
* [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 =
{| class="wikitable"
|-
! Metrics !!
|-
| Talos test to measure parallel page loads || {{Bug|1409002}}
|-
| Telemetry probe to measure background process activity || {{Bug|1388280}}
|-
! Tuning !!
|-
| Process selection based on memory footprint || {{Bug|1388277}}
|-
| Restarting troubled processes || {{Bug|1374353}}
|-
| Selecting max content process count based on users machine || ...
|}
 
= Future plans =
{| class="wikitable"
! Memshrink !!
|-
| Compressing strings in JSMs || ...
|-
| Reduce resources loaded in the CP || ...
|-
| Reduce static tables || ...
|-
| Reduce or improve per process caches || ...
|-
! Long term !!
|-
| Suspending / Freezing background tabs and processes || ...
|-
| Battery life saving mode || ...
|-
| Sharing scripts || ...
|}


== Testing ==
= Bug tracking =
* [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 ==
== Triage ==
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1336380 Improve content process startup time]
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=13712205&resolution=---&status_whiteboard_type=anywordssubstr&query_format=advanced&status_whiteboard=e10s-multi%3AM%3F%2C%20e10s-multi%3A%3F Triage list] ('e10s-multi:?' in whiteboard)


== Bug tracking ==
== Priorities ==
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=13115346&resolution=---&status_whiteboard_type=anywordssubstr&query_format=advanced&status_whiteboard=%5Be10s-multi%3AM%3F%5D%20%5Be10s-multi%3A%3F%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED '''Triage'''][e10s-multi:?] in whiteboard
* [https://bugzilla.mozilla.org/buglist.cgi?priority=P1&list_id=13845618&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&status_whiteboard_type=allwordssubstr&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&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED P2]
* [https://bugzilla.mozilla.org/buglist.cgi?priority=P3&list_id=13845618&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=e10s-multi%3A%2B&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED P3]


== Links ==
= Links =
* [https://docs.google.com/a/mozilla.com/document/d/14E5ERudaZrx-qcOLttXGkV6DgHIyp3h9IZoqnhuO7X8/edit Process Model] (2012)
* [https://docs.google.com/a/mozilla.com/document/d/14E5ERudaZrx-qcOLttXGkV6DgHIyp3h9IZoqnhuO7X8/edit Process Model] (2012)
* Recent [https://groups.google.com/forum/#!searchin/mozilla.dev.platform/e10s$20multiple$20processes/mozilla.dev.platform/NHIjpGvOelE/_A9IJWsP0fUJ dev.platform] discussion
* Recent [https://groups.google.com/forum/#!searchin/mozilla.dev.platform/e10s$20multiple$20processes/mozilla.dev.platform/NHIjpGvOelE/_A9IJWsP0fUJ dev.platform] discussion


== Meetings ==
= Teams =
We are meeting every week at 9am PDT (6pm CEST) starting on June 28.
TBD

Latest revision as of 12:46, 6 November 2017

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.

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 further optimization. Memory consumption and content process startup time optimization, memory balancing 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.

Status

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

Content process startup time

  • ~300ms - on most platforms (the OSX issue is investigated under: bug 1404309)
  • The preallocated process manager is enabled from 58

Current work

Metrics
Talos test to measure parallel page loads bug 1409002
Telemetry probe to measure background process activity bug 1388280
Tuning
Process selection based on memory footprint bug 1388277
Restarting troubled processes bug 1374353
Selecting max content process count based on users machine ...

Future plans

Memshrink
Compressing strings in JSMs ...
Reduce resources loaded in the CP ...
Reduce static tables ...
Reduce or improve per process caches ...
Long term
Suspending / Freezing background tabs and processes ...
Battery life saving mode ...
Sharing scripts ...

Bug tracking

Triage

Priorities

Links

Teams

TBD