CODEWITHSUNDEEP
c#azureazure-iot-hubazure-iot-edge
OverflowStack
OverflowStack

Reputation: 919

Dealing with frequent device Twin reads and throttling

Inspired by Azure IoT PCS Remote Monitoring repository I started working on my own IoT system based on Azure Iot Hub.

Similar to IoT PCS repository, I have an API endpoint (/api/devices) that returns a list of devices on the my IoT Hub - when client makes a request I use Microsoft.Azure.Devices SDK and RegistryManager to create a query and return a list of device twins. This API endpoint is used and consumed on my front end SPA app.

var result = await registryManager
                .CreateQuery("SELECT * FROM devices", 100)
                .GetNextAsTwinAsync(options);

This works great, however I discovered that if you run this query too often, quite fast you'll encounter throttling. I'm using S1 tier and, if I understand it correctly, I'm allowed to make up to 20 Twin queries every minute. This doesn't exactly scale well assuming my system and client base grows. Even on the higher tiers, the scale is not really that high.

The question is - how are you expected to deal with this limitation?

So far my best idea is to replicate IoT Hub device (Twin) data into CosmosDB/SQL Server and synchronize all the twin changes using IoT Hub endpoints. Then instead of querying IoT Hub directly, I'd query CosmosDb/SQL instead. I don't know if this approach would be any good or not though.

Upvotes: 2

Views: 578

Answers (2)

Roman Kiss
Roman Kiss

Reputation: 8255

The question is - how are you expected to deal with this limitation?

Based of the doc Reference - IoT Hub quotas and throttling:

Throttle    Free, B1, and S1    B2 and S2       B3 and S3
--------------------------------------------------------------
Queries       20/min/unit       20/min/unit     1,000/min/unit

You can scale-out your queries increasing a number of unit (up to 200 units) using a portal or programmatically, for instance REST PUT request based on the needs.

Upvotes: 1

tmaj
tmaj

Reputation: 35075

I can confirm that subscribing to twin changes and replicating desired and reported to a db which is read often is a viable solution.

The pipeline looks something like this: IoT Hub -> Message routing:Endpoint -> Consumer -> To Db -> Fast unlimited reads.

Upvotes: 2

Related Questions