Tanzu Application Service (TAS for VMs) Autoscaler may not reliably scale apps when using scaling rules based on CPU utilization. This is because app CPU utilization data may vary greatly based on the number of CPU cores on Diego cells and the app density.

The CPU behavior in ERT is effected by both the number of cores on the host Cell and the app density on the host cell. Because the CPU can be represented in ERT as a value greater than 100%, and is dependent on data the user may not be able to access, we advise users to take one of two approaches:

Caution We do not recommend approach #2.

  1. If the app can be characterized by other metrics (HTTP currently) then use other metrics. Autoscaler recently added HTTP latency and throughput.

  2. If CPU is the only indicator of load on a particular app, then the user will need to profile the app in the target environment to understand the CPU metric behavior in that specific environment. Also, if users do know the underlying architecture of the Cells (cores), those values can be used to calculate a valid CPU expectation. This is still susceptible to wide variations in the metrics.

Because these realities present a problem to users and to other components (Autoscaler, for example), there is an initiative to get more valuable and reliable CPU metrics into the platform.

As the values are calculated and produced by the Garden container backend, there is ongoing effort to improve the reliability and usefulness of this metric provided by Garden.

In the meantime, Autoscaler did have a bug in the GUI in which the user could not enter a value of 99%. This has been fixed in recent releases.

The API has supported these larger values without any issues. The resulting behavior is deterministic from an autoscaling perspective, but is still susceptible to the CPU value variations mentioned.

For more information:

check-circle-line exclamation-circle-line close-line
Scroll to top icon