Closed Bug 1722112 Opened 11 months ago Closed 10 months ago

[Experiment] Pref-Flip Experiment: Fission Process Count Fx 92.0 to 94.0 Nightly


(Shield :: Shield Study, task, P3)


(firefox90 disabled, firefox91 disabled, firefox92 affected)

Tracking Status
firefox90 --- disabled
firefox91 --- disabled
firefox92 --- affected


(Reporter: experimenter, Assigned: cpeterson)




(Whiteboard: [fission:m8])

User Story

Delivery Type: Pref Flip Experiment

    What is the preference we will be changing


    What are the branches of the experiment and what values should
    each branch be set to?

- Treatment process-count-4 50%:

Value: 4

This treatment branch uses up to four content processes per site.
- Control process-count-1 50%:

Value: 1

The control branch uses one content process per site.

    What version and channel do you intend to ship to?

100% of Nightly Firefox 92.0 to 94.0

    Are there specific criteria for participants?

* Require telemetry environment's "fissionEnabled" == true so we only draw from the ~65% of Nightly users who are already using Fission.

NOTE: We want this experiment to run for all Fission Nightly users (so 50% of them are treatment, 50% are control). Therefore we need to target 100% of Nightly because the fissionEnabled filter will select just the Fission users.
Countries: all

Locales: all

    What is your intended go live date and how long will the experiment run?

Aug 03, 2021 - Aug 31, 2021 (28 days)

    What is the main effect you are looking for and what data will you use to
    make these decisions?

What is the main effect you are looking for and what data will you use to make these decisions? What metrics are you using to measure success?

Same as all of our Fission Beta experiments, the most recent being

We want to be able to monitor the difference in stability and performance metrics between clients with and without Fission enabled. The Fission Experiment Plan ( has a detailed list of telemetry probes (and expectations for each probe: up, down, or flat).

We plan to monitor these metrics:

Memory metrics:

- `GC_MS`

Performance metrics:


Engagement metrics:

- Number of users submitting pings
- `browser.engagement.total_uri_count`
- `browser.engagement.tab_open_event_count`
- `browser.engagement.max_concurrent_tab_count`

Stability metrics:

- Main process crash rate (per 1000 usage hours), 32-bit and 64-bit
- Content process crashes (per 1000 usage hours) (excluding ShutDownKills), 32-bit and 64-bit
- `crash_tab_ui_presented`
- `crash_subframe_ui_presented`
- `oom_crashes` (per 1000 usage hours), 32-bit and 64-bit
- `shutdown_crashes` (per 1000 usage hours)

Do you plan on surveying users at the end of the delivery? No.

 Estimated Total Enrolled Clients: 360,000 (assuming we enroll 15% of 1.2M Beta + Dev Edition users running Windows or macOS)

    Who is the owner of the data analysis for this experiment?

    Will this experiment require uplift?


    QA Status of your code:

TBD? This experiment is not much different from our Fission Beta experiments like

    Link to more information about this experiment:

Fission Process Count

Track the stability and performance effects of increasing the number of Fission content processes.

Experimenter is the source of truth for details and delivery. Changes to Bugzilla are not reflected in Experimenter and will not change delivery configuration.

Data Science Issue:
More information:

Whiteboard: [fission:m8]
User Story: (updated)
Summary: [Experiment]: Pref-Flip Experiment: Fission Process Count → [Experiment] Pref-Flip Experiment: Fission Process Count Fx 92.0 to 94.0 Nightly
Start Date: 2021-08-03 End Date: 2021-08-31
Closed: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.