Closed Bug 1603119 Opened 5 years ago Closed 3 years ago

[meta] Meta: Prestart enough content processes to avoid delays when loading typical pages in Fission

Categories

(Core :: DOM: Navigation, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
Fission Milestone MVP
Tracking Status
firefox92 --- affected

People

(Reporter: jesup, Assigned: jesup)

References

(Blocks 1 open bug)

Details

(Keywords: meta, perf, Whiteboard: fission-perf, fission-soft-blocker)

Many pages have 1 or more iframes which in Fission are likely to need new content processes to load. We need to attempt to have enough prestarted processes that we don't delay startup waiting for processes to load and initialize.

The number to prestart probably should be adaptive to a number of things:

  • The process creation delay for the machine/OS
    ** Different OSes vary in the overhead to create a process
    ** Processor speed and disk type also affect process start time
    ** Memory pressure may affect it
  • History of the number of processes needed
  • (maybe) Prediction based on the top-level domain being loaded
  • (maybe) The origins already existing in processes (common iframe origins)

We could use an algorithm that dynamically adapts to whether it finds it needs to create more on-the-fly too often, which will help a lot with the scaling to the machine and the load on the machine, perhaps with some presets or measurements during browser startup to seed the adaption (since we create several processes during startup, we can measure the time it takes).

We can aggressively create processes during parse similar to how we speculatively connect; this might help especially on machines with spare cores. Low-core machines might see no improvement if process creation takes away from parsing of the main page, and even might (maybe) hurt visual metrics if it delays mainpage rendering to speed an iframe creation time.

Depends on: 1603267

<wrong bug>

Fission Milestone: --- → M6
Priority: -- → P3

:jesup, I believe you're actively working on this right now. Can this bug be duped against your prelaunch bug?

Flags: needinfo?(rjesup)
Flags: needinfo?(rjesup)
Keywords: meta
Summary: Prestart enough content processes to avoid delays when loading typical pages in Fission → Meta: Prestart enough content processes to avoid delays when loading typical pages in Fission
Summary: Meta: Prestart enough content processes to avoid delays when loading typical pages in Fission → [meta] Meta: Prestart enough content processes to avoid delays when loading typical pages in Fission

Tracking for Fission M7 Beta because this perf meta bug doesn't need to block Fission Nightly.

Fission Milestone: M6 → M7

We no longer block the main page so we should look into lowering the preallocated process to maybe 1, and then attempt to allocate 2 more while DocumentChannel waits for Necko channel to return.

Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Whiteboard: [qf:p1:pageload][fission] → [qf:p1:pageload] fission-perf

This is not required for Beta and we can revisit this later before MVP to see if there's work identified to do here.

Fission Milestone: M7 → MVP

Removing from QF since it's a meta bug.

Whiteboard: [qf:p1:pageload] fission-perf → fission-perf

Randell, can we close this meta bug as fixed?

Flags: needinfo?(rjesup)

This bug is a soft blocker for Fission MVP. We'd like to fix it before our Release channel rollout, but we won't delay the rollout waiting for it.

Whiteboard: fission-perf → fission-perf, fission-soft-blocker
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(rjesup)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.