Ok, last week was weak. Hopefully my grammar is correct. So I want to make it up too you by giving you some meat this week. I’ve been involved lately in several discussions regarding SQL Azure capacity limits (performance, not storage) and throttling. Admittedly, this little topic, often glanced over, has bitten the butts of many an Windows Azure project.
So lets look at it a little more closely. Shall we?
Types of Throttling
Now if you go read that link I posted last week on SQL Azure Error Messages, you’ll see that there are two types of throttling that can occur:
Soft Throttling – “kick in when machine resources such as, CPU, IO, storage, and worker threads exceed predefined thresholds”
Hard Throttling – “happens when the machine is out of a given resource”
Now SQL Azure is a multi-tenant system. This means that we have multiple tenants (databases) that will sit on the same physical server. There cold be several hundred databases that share the same hardware. Now SQL Azure will use soft throttling to try and make sure that all these tenants get a minimum number of resources. When a tenant starts pushing those limits, soft throttling will kick in and the SQL Azure fabric will try to move tenants around to rebalance the load.
Hard throttling means no new connections. You’ve maxed things out (storage space, worker process, cpu) and drastic steps should be taken to free those resources up.
SQL Azure Resources
Also in that article, we find the various resource types that we could get throttled on:
- Physical Database Space
- Physical Log Space
- LogWriteIODelay
- DataReadIODelay
- CPU
- Database Size
- Internal
- SQL Worker Threads
- Internal
- Now when an error message is returned, you’ll have throttling types for one or more of these resources. The type could be “no throttling”, could be “soft”, or it could be “hard”.
Throttling Modes
Now if all this wasn’t confusing enough, we have three types of throttling. Well technically four if you count “no throttling”.
Update/Insert – can’t insert/update, or create anything. But can still drop tables, delete rows, truncate tables, read rows.
All Writes – all you can do is read. You can’t even drop/truncate tables.
Reject All – you can’t do anything except contact Windows Azure Support for help.
Now unlike the throttling type, there is only one mode returned by the reason.
But what can we do to stop the errors?
Now honestly, I’d love to explain Andrew’s code to you for deciphering the codes. But I was never good with bitwise operations. So instead, I’ll just share the code and along with a sample usage. I’ll leave it to folks that are better equipped to explain exactly how it works.
The real question is can we help control throttling? Well if you spend enough time iterating through differing loads on your SQL Azure database, you’ll be able to really understand your limits and gain a certain degree of predictability. But the sad thing is that as long as SQL Azure remains a shared multi-tenant environment, there will always be situations where you get throttled. However, those instances should be a wee bit isolated and controllable via some re-try logic.
SQL Azure is a great solution, but you can’t assume the dedicated resources you have with on-premises SQL Server solution. You need to account for variations and make sure your application is robust enough to handle intermittent failures. But now we’re starting down a path of trying to design to exceed SLA’s. And that’s a topic for another day. 
