Forum Discussion
Capacity Usage and Interactive Delay
This may be related to the current issues with autoscale. It basically doesn't.
This video by my colleague Pat Mahoney has some great tips for understanding the Capacity Metrics app: https://www.youtube.com/watch?v=EuBA5iK1BiA We do try to be generous with throttling and only do it when the capacity is consistently overloaded. Take a look at the timepoint detail page to see what's happening in more detail.
This video by my colleague Pat Mahoney has some great tips for understanding the Capacity Metrics app: https://www.youtube.com/watch?v=EuBA5iK1BiA We do try to be generous with throttling and only do it when the capacity is consistently overloaded. Take a look at the timepoint detail page to see what's happening in more detail.
We do try to be generous with throttlingThat's one way to phrase it. We, on the other hand, have a really hard time understanding why we cannot pay down the smoothing debt earlier, for example with CUs from our other capacities that may not be as busy. Mind you, we have Premium (not Fabric) SKUs, and we paid for them on a multi year contract. So we are basically paying twice. Or thrice if you want, because once a capacity is locked up (ie interactive rejection) there is no way out but to wait for x hours and tell our users that there is nothing we can do.
And yes, Autoscale wouldn't have helped either even if we had decided to enable that. By the way, is that bug fixed now?
Thank you very much Chris, i'll take a look and pass it forward to my team. Keep up with the gold content.
cpwebb , i have another question. Why capacities with autoscale enable have a reduced Interactive Delay proportional to the number of enabled Vcores ? Here i have a capacity with 87% background - figure 1 - (that's bad i know) and 58% base interactive delay whilist having 4 extra vCores enabled (P1 x 1.5) , but not active. Is this gap normal ? Am i'm being billed even if the extra vCores are inactive ? - figure 2
Interactive Delay graph has to be above 100% threshold to actually impact users. Your chart says that your combined interactive and background usage is not yet bad enough to initiate interactive delay. Consumption needs to be above 100% CU for 10 minutes to start causing interactive delay.
Yes, i'm aware of that, but in my case as i have 78% background around 02 AM i should also have 78% interactive delay, but i'm still a litter over 50% while also having 4 extra vCores enabled (but inactive). In other capacities without auto scale enabled i have a 1:1 background-interactive delay (%) ratio. Sorry if my previous message wasn't as clear.