What is the best way to identify throttling

[tomkerkhove]

What is the best way to identify throttling other than checking for the exceptions? Are there response headers, or other ways to keep track of that?

For example, we have an assumption that we are throttled on the IP level and want to see how we can identify this.

[drwill-ms]

Hi Tom -

For context, are we talking about device or service SDK? Hub? Which transport protocol are you using?

Thanks,
David

[tomkerkhove]

Actually both for device and service in .NET.

[drwill-ms]

There are many ways to look at throttling. The most straight-forward one is maximum number of operations per unit of time. Hub defines many additional throttling conditions and limits, so I'll try to include as many of them as possible. You can read more about all hub quotas and throttling.

In all cases, the IsTransient property can be checked if the client should attempt retry, or not.

Service client

For the service SDK, there are several clients: RegistryManager, ServiceClient, JobsClient, and DigitalTwinsClient. Transport protocol can influence the kind of errors returned, so be aware of the table that shows which clients and operations happen over HTTP and AMQP.

When you are being throttled in a data-plane SDK, it comes back as an error on the response and is surfaced to the SDK user as an exception. Some of these errors are documented by the service and here is one example for ThrottlingException with an HTTP response code of 429 with a sub code of 001.

• For any operation, if it exceeds the number of operations per second allowed, you could see a ThrottlingException.
• For any operation throttled over AMQP, you could see a IotHubThrottledException.
• When quota has been exceeded, you could see a QuotaExceededException.
• Although unlikely, it is possible the service is having trouble managing load. The reported error we'd see in that case is ServerBusyException.
• For import/export jobs, you could get a unique throttling exception of JobQuotaExceededException for # of active jobs allowed, given the size of the hub.
• When sending cloud-to-device messages, if the device is not processing them fast enough, you could see DeviceMaximumQueueDepthExceededException.
• If the cloud-to-device message exceeds a maximum threshold, you could see MessageTooLargeException.
• When doing bulk device registry operations that exceed the published batch limit, one can get TooManyDevicesException.
• When deploying more than 50 modules to an Edge device, one can get TooManyModulesOnDeviceException.
• If the Azure subscription is disabled due to spending limits, you could see IotHubSuspendedException. This is one that would not be retried automatically, but you'd be unlikely to see it if your subscription is a normal type.

Device client

For a device SDK, depending on which protocol is used, it may simply be disconnected, or may get an exception. The device client has built-in retry policy, and if left to the default, it will retry indefinitely. However, if the retry policy is overridden, it may be necessary to handle exceptions from throttling. Many of the same exceptions apply on the device. You can see the list here.

We have a good code sample that describes how to author a device/module app. Please take a look at that to understand how to handle connection events.

Does this help?