(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2) > [...] > 2) The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted? I don't understand what "pushes unrelated to alerts" means. If the suggestion is to implement an heuristic to somehow determine what to omit, that's definitely not something we can practically do. The load on hardware pools is something expected. It's a drawback from reducing the job frequency from every 5 pushes to every 20 pushes. There's 4 times more missing data. Thus, the load is 4 times bigger than it used to be. Perf sheriff need this (missing) data one way or the other. And we surely need it ASAP, because we have very clear & strict KPIs. If the load is a problem, more advanced Taskcluster mechanisms should be employed.
Bug 1698018 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2) > [...] > 2) The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted? I don't understand what "pushes unrelated to alerts" means. If the suggestion is to implement an heuristic to somehow determine what to omit, that's definitely not something we can practically do. The load on hardware pools is something expected. It's a drawback from reducing the job frequency from every 5 pushes to every 20 pushes. There's 4 times more missing data. Thus, the load is 4 times bigger than it used to be. Perf sheriffs need this (missing) data one way or the other. And we surely need it ASAP, because we have very clear & strict KPIs. If the load is a problem, more advanced Taskcluster mechanisms should be employed.
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2) > [...] > 2) The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted? I don't understand what "pushes unrelated to alerts" means. If the suggestion is to implement an heuristic to somehow determine what to omit, that's definitely not something we can practically do. Perf regressions tend to have very unexpected culprits. The load on hardware pools is something expected. It's a drawback from reducing the job frequency from every 5 pushes to every 20 pushes. There's 4 times more missing data. Thus, the load is 4 times bigger than it used to be. Perf sheriffs need this (missing) data one way or the other. And we surely need it ASAP, because we have very clear & strict KPIs. If the load is a problem, more advanced Taskcluster mechanisms should be employed.
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2) > [...] > 2) The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted? I don't understand what "pushes unrelated to alerts" means. If the suggestion is to implement an heuristic to somehow determine what to omit, that's definitely not something we can practically do. Perf regressions tend to have very unexpected culprits. The load on hardware pools is something expected. It's a drawback from reducing the job frequency from every 5 pushes to every 20 pushes. There's 4 times more missing data. Thus, the load is 4 times bigger than it used to be. Perf sheriffs need this (missing) data one way or the other. And we surely need it ASAP, because we have very clear & strict KPIs. If the load is a problem, more advanced Taskcluster mechanisms should be employed or the pool size should be increased.