Bug 1613448 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

A preliminary investigation shows that our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million (currently) to 190 million rows.

####  Investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.

####  Investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
Of course, this would further increase the pressure on bug 1343328 (not yet sure to what degree).

####  Investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
Of course, this would further increase the pressure on bug 1343328 (not yet sure to what degree).

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
WRT the pressure on bug 1343328, the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

If with the addition of these new metrics we double the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
WRT the pressure on bug 1343328, the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double** the amount of tests we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
WRT the pressure on bug 1343328, the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
WRT the pressure on bug 1343328, we'd consume from  **690K ids/day** (currently) to **840K ids/day**. (Basically the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.) 

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from 140 million rows (currently) to 190 million.
WRT the pressure on bug 1343328, we'd consume our available ids **20% faster**, from  **690K ids/day** (currently) to **840K ids/day**. (Basically the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.) 

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from **140 million rows** (currently) to **190 million**.
WRT the pressure on bug 1343328, we'd consume our available ids **20% faster**, from  **690K ids/day** (currently) to **840K ids/day**. (Basically the browser/raptor tests would consume from **150K ids/day** (currently) to **300K ids/day**.) 

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from **140 million rows** (currently) to **190 million**.
WRT the pressure on bug 1343328, we'd consume our available ids **20% faster**, from  **690K ids/day** (currently) to **840K ids/day**. (Basically the browser/raptor tests would consume from 150K ids/day (currently) to 300K ids/day.) 

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).
A preliminary investigation shows that this might increase the database' s capacity from **140 million rows** (currently) to **190 million**.
WRT the pressure on bug 1343328, we'd consume our available ids **20% faster**, from  **690K ids/day** (currently) to **840K ids/day**. (Basically the browser/raptor tests would consume from 150K ids/day (currently) to 300K ids/day.) 

####  Preliminary investigation breakdown

Our *relatively* active raptor & browsertime tests generated around 39 million data points for the whole year.
Our database currently holds 140 million of them.

**If** with the addition of these new metrics **we double the amount of tests** we run, this implies the database' s total capacity will increase to 180 million rows (in the course of a year). This can turn out to be a bare minimum, especially if we implement [FXP-1450 - Keep stalled data that has historical value](https://jira.mozilla.com/browse/FXP-1450) (which could further increase it with several millions rows).

([Redash queries](https://sql.telemetry.mozilla.org/queries/77615/source) used for this investigation)

Back to Bug 1613448 Comment 10