Provide better metrics for capacity of APIM instances
The "fundamental" question is how we can follow the "real" capacity of APIM instances.
Because the "capacity" metric is currently calculated (according to the documentation) as a "mix" of :
- Azure internal processes CPU which are out of (user) control : VM, OS, anti-spyware / viruses, but certainly many others)
- The memory usage (even if you don "t use" caching "behavior)
- The incoming request queue.
The documentation says:
"Capacity can also spike intermittently or be greater than zero even if there are no requests being processed. It happens because of system- or platform-specific actions and should not be taken into consideration when deciding whether to scale an instance. "
In fact, analyzing the average capacity metric is confusing as it don"t seems to reflect the treatement of API calls. For example we can have a high "capacity" metric during several hours while we know your traffic flow is very low (for example during off-peaks night hours) ?!
To illustrate, on an HTTP server, you can look at the CPU capacity, the memory usage but the average of free versus used sockets and the length of the connection queue too. An "automatic" correlation of all these elements, like with Azure APIM, is less "meaningful" and sometime confusing.
In summary, current "capacity" metric don't seems to be able to "feel" the real capacity of our APIM services.
The idea is to provide more accurate metric(s) to have a better understanding of the traffic flow capacity of APIM instances to be able to better plan capacity scales.
Capacity metric reflects total load on resources assigned to a specific API Management service instance – data plane, management plane, developer portal, etc.
Thanks for your fedback. But the suggestion was to give a better metric to follow trafic flow capacity of APIM ;)