On Wed, Jul 11, 2018 at 02:42:11PM +0200, David Bruant wrote:
2018-07-10 20:19 GMT+02:00 Kris Maglione <kmagli...@mozilla.com>:
The problem is thus: In order for site isolation to work, we need to be
able to run *at least* 100 content processes in an average Firefox session
I've seen this information of 100 content processes in a couple places but
i haven't been able to find the rationale for it. How was the 100 number
picked?
So, the basic problem here is that we don't get to choose the number of
content processes we'll have. It will depend entirely on the number of
origins that we load documents from at any given time. In practice, the
biggest contributing factor to that number tends to be iframes (mostly
for things like ads and social widgets).
The "100 processes" number was initially chosen based on experimentation
(basically, counting the number of origins loaded by typical pages on
certain popular sites) and our knowledge of typical usage patterns. It's
meant to be a conservative estimate of the number of processes typical
users are likely to hit on a regular basis, though hopefully not all the
time.
For heavy users, we expect the number to be much higher[1]. And while those
users typically have more RAM to spare, they also tend not to be happy
when we waste it.
We also need to add to that number the Activity Stream process that
hosts things like about:newtab and about:home, the system extension
process, processes for any other extensions the user has installed
(which will each likely need their own processes for the same reasons
each content origin will), and the pre-loaded web content process[4].
We've been working on improving our estimates by collecting telemetry on
the number of document groups[2] per tab group[3]:
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=1&end_date=2018-06-30&keys=__none__!__none__!__none__&max_channel_version=nightly%252F63&measure=TOTAL_HTTP_DOCGROUPS_PER_TABGROUP&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-06-25&table=0&trim=1&use_submission_date=0
But we don't have enough data to draw conclusions yet.
Would 90 prevent a release of project fission?
This isn't really something we get to choose. The closest I can come is
something like "would an overhead of 1.1GB prevent a release of project
Fission". And, while the answer may turn out to be "no", I'd prefer not
to speculate, because that's a decision we'd wind up paying for with
user dissatisfaction.
There are some other hacks that we can use to decrease the overall
overhead, like aggressively unloading background tabs, and flushing
their resources. We're almost certainly going to wind up having to do
some of that regardless, but it comes at a performance cost. The more
aggressive we have to be about it, the less responsive the browser is
going to wind up being. So, again, the shorter we fall on our memory
reduction efforts, the more we're going to pay in terms of user
satisfaction.
How will the rollout happen?
Will the rollout happen progressively (like 2 content processes soon, 4
soon after, 10 some time after, etc.) or does it have to be 1 (current
situation IIUC) then 100?
* Andrew McCreight created a tool for tracking JS memory usage, and figuring
out which scripts and objects are responsible for how much of it
(https://bugzil.la/1463569).
How often is this code run? Is there a place to find the daily output of
this tool applied to a nightly build for instance?
For the moment, it requires a patched build of Firefox, so we've been
running it locally as we try to track down and fix memory issues, and
Andrew has been periodically updating the numbers in the bug.
I believe Andrew has been working on updating the patch to a land-able
state (which is non-trivial), after which we'll hopefully be able to get
up-to-date numbers from automation.
[1]: Particularly readers of TechCrunch, which regularly loads 30
origins on a single page.
[2]: Essentially documents of different origin.
[3]: Essentially sets of tabs that are tied together because they were
opened by things like window.open() calls or link clicks from other
tabs.
[4]: Which currently have only one of, but may need more of in the
future in order to support loading several iframes in a given page
without noticeable lag or jank.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
