Capacity Usage and Interactive Delay

[gabrielPerson]

I have a P1/F64 capacity and still couldn't understand why i'm not reaching 100% intereactive delay even when having +100% CU% during several minutes. I've read the recent microsoft content regarding capactity usage regarding usage and delay but on recent days these charts don't make much sense to me.

[lbendlin · Accepted solution]

This may be related to the current issues with autoscale. It basically doesn't.

[cpwebb]

>>why we cannot pay down the smoothing debt earlier, for example with CUs from our other capacities that may not be as busy.
This is feedback we've heard from a few customers and we may allow something like this in the future - I agree it seems like a reasonable thing to do. No promises though.

We're also working hard on features to stop a single user from consuming all the resources in a capacity and throttling it for everyone.

[cpwebb · Accepted solution]

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.

[gabrielPerson]

@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

[lbendlin]

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.

[gabrielPerson]

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.

[lbendlin]

We do try to be generous with throttling 

That'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?

[gabrielPerson]

Thank you very much Chris, i'll take a look and pass it forward to my team. Keep up with the gold content.

[lbendlin]

Interactive delay kicks in after 10 continuous minutes of 100% or more utilization.   That's what we experience.

Do you have autoscale enabled on your SKU?

[gabrielPerson]

Yes we do, fortunately we didn't hit the 100% interactive delay threshold to trigger autoscale but it should've happened. This was more than a full hour of +100% utilization

[lbendlin · Accepted solution]

This may be related to the current issues with autoscale. It basically doesn't.