Fabric offers the option to temporarily burst the capacity to max three times the power that is associated with the SKU.
This works fine, but at some point the overage needs to be burnt down, leading to throttling or even rejection.
I'd like to have the option to limit bursting or even turn it off to prevent the throttling and rejection all together. This would have an impact on the duration of interactive and/or background processes. Overall, I think it will lead to a better user experience when it's just clear that the chosen SKU is insufficient for that point in time and should be upgraded to a higher one. This is an easier discussion with a client than having to explain why there were error messages about the capacity 'not working'.
7 Comments
- fbcideas_migusrNew Member
A configurable parameter for bursting would be nice. For example x times bursting.
You're alone on the capacity because you're the sole dev? Set it to 10 and enjoy the speed!
You have to share a capacity globally and you don't want to borrow capacity from other time zones? Set it to 1 (which would mean no bursting).
- thisissanthoshr
Microsoft Employee
Thank you sharing this. For spark workloads I have included this to my list for the upcoming semester to make the burst factor configurable.
- dvnnaiduNew Member
This is a must and also there is a big in the bursting when pausing a capacity. When capacity is paused for that second consumption shows as in million of CUs
- fbcideas_migusrNew Member
Is not a rejection, but is a limit . . .
SKU Guardrail: Limit the burstable SKU escalation to a maximum
- thisissanthoshr
Microsoft Employee
Have added it to our backlog and this ask is under internal review. Stay tuned for updates. Thank you! - fbcideas_migusrNew MemberStatus added:Under Review
- AnonymousNot applicable
Thank you for this posting. We released a preview of Surge Protection that limit the allowed background usage. This can be used for the purpose of limiting bursting, since background requests can be rejected much sooner than the default configuration. Here's the link. Let us know if that's helpful for this idea or if there's more we should consider doing. https://blog.fabric.microsoft.com/en-us/blog/announcing-surge-protection-public-preview
Recent ideas
Pipeline: Activity-level Run Conditions (No IF Container Required)
We need the ability to add a "Run if" condition directly to every pipeline activity. Like, in each acticity's settings. One of the biggest readability issues in Fabric Pipelines is that conditional ...frithjof_v23 hours agoCommunity ChampionNew25Views3likes1CommentPipeline: New Routing activity as an improvement to IF and Switch
The current If Condition and Switch activities create large nested containers that own all activities inside their branches. These containers make the canvas much harder to read. Instead, add a lig...frithjof_v23 hours agoCommunity ChampionNew12Views1like1CommentEnhance Workspace Throttling to Allow Targeted Limits on Individual Workspaces
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } The current workspace throttling design should be enhanced to allow Fabr...kyleleonard1 day agoNew MemberNew28Views5likes0Comments