Bugzilla

here are a few challenges with using Azure VMs as a performance baseline.

First, for standard shared Azure VMs, we do not control the hypervisor, host placement, or the underlying physical hardware. The host environment can change due to Azure maintenance, live migration, hardware decommissioning, or other platform-level events, and there may also be differences across regions or zones.

Second, performance can be affected by host-level scheduling and contention from other workloads running on the same physical hardware. That makes it harder to determine whether a performance shift came from Firefox, the test environment, or the cloud platform itself.

Also worth noting: we are already exploring options to potentially replace the non-reference hardware, so I think Azure VMs could still be useful as a comparison point. I would just be cautious about treating them as a stable replacement for reference hardware without more validation.

For testing, we may also want to create a separate pool isolated to a specific Azure region, and investigate which VM size or type best matches the workload. That would help reduce variability and give us a cleaner signal while we evaluate whether this is a viable path.

There are a few challenges with using Azure VMs as a performance baseline.

First, for standard shared Azure VMs, we do not control the hypervisor, host placement, or the underlying physical hardware. The host environment can change due to Azure maintenance, live migration, hardware decommissioning, or other platform-level events, and there may also be differences across regions or zones.

Second, performance can be affected by host-level scheduling and contention from other workloads running on the same physical hardware. That makes it harder to determine whether a performance shift came from Firefox, the test environment, or the cloud platform itself.

Also worth noting: we are already exploring options to potentially replace the non-reference hardware, so I think Azure VMs could still be useful as a comparison point. I would just be cautious about treating them as a stable replacement for reference hardware without more validation.

For testing, we may also want to create a separate pool isolated to a specific Azure region, and investigate which VM size or type best matches the workload. That would help reduce variability and give us a cleaner signal while we evaluate whether this is a viable path.

There are a few challenges with using Azure VMs as a performance baseline.

First, for standard shared Azure VMs, we do not control the hypervisor, host placement, or the underlying physical hardware. The host environment can change due to Azure maintenance, live migration, hardware decommissioning, or other platform-level events, and there may also be differences across regions or zones.

Second, performance can be affected by host-level scheduling and contention from other workloads running on the same physical hardware. That makes it harder to determine whether a performance shift came from Firefox, the test environment, or the cloud platform itself.

Also worth noting: we are already exploring options to potentially replace the non-reference hardware.

For testing, we may also want to create a separate pool isolated to a specific Azure region, and investigate which VM size or type best matches the workload. That would help reduce variability and give us a cleaner signal while we evaluate whether this is a viable path.