Publishing Rate Limit

  • 3 minute(s) read

Servitly receives data from connected products through built-in and plugins IoT Connectors, in each case this data stream is constrained by two levels a broader one which is commercial and affects the entire DPS, and a system level affecting individual connected products.

Commercial Limit

Within the commercial offer, the OEM agrees that each connected product (thing) can publish a certain number of data points each hour. This limit should be considered as the average between all things and data points published during the month.
For example, if the limit is set at 600 data-points/hour, you can have one thing publishing at 200 data-points/hour and another thing publishing at 800 data-points/hour, the average is 600 data-points/hour.And also, you can have a thing publishing from 08:00 AM to 08:00 PM at 1200 data-points/hour and from 08:00 PM to 08:00 AM at 0 data-points/hour (e.g. offline thing), the average is 600 data-points/hour.

Each data-point that exceeds the commercial limit is counted as an extra DPH that will increase costs.
In the Console, by entering the Overview page of your environment, and then Billing, you can have evidence of the amount of DPH consumed by your connected products.

System Limit

In addition to the commercial limit, there is a system rate limit, which is higher than the previous one, and used to limit things that could publish too many data points (e.g., bugs in the firmware).
The system rate limit is verified by a bucket based on a sliding window. A token is consumed for each data point published, and the bucket ensures a certain amount of tokens per period of time.

This means that each thing has a number of tokens it can consume in a period of time. When the thing runs out of tokens, the excess data points are discarded. The period is subdivided into 60 slots, each of which has a certain number of tokens depending on the overall rate limit, the default rate limit is 3600 data-points/hour, if you need more, you must contact the Servitly support. When a token is used, that token is restored (and can be used again) after the time period has passed.

For example, suppose a limit of 3600 data points/hour, this means 3600 tokens/hour and 60 tokens available every minute. If a thing uses 600 tokens at 6:05 PM, the thing could only publish up to another 3000 data points until 7:04 PM.
At 7:05 PM, the thing will get 60 tokens back and so on every minute forward.

Each environment has specific limitations, you can verify them in the Environment Types and Limits article.

Overdraft

Connected products can exceed the rate limit for a short time period, this is called Overdraft of the rate limit. Suppose that the bucket size is 3600 tokens (which cannot be exceeded at any given time), with a "refill rate" of 60 tokens per minute that continually increases tokens in the bucket. In other words, if the client consumes an average of 60 tokens per minute, it will never be throttled, and moreover, the client has overdraft equals to 60 tokens which can be used if the average is a little bit higher than 60 tokens/minute in a short time period.

Excess data rejection

Data points exceeding the limit are discarded, and the way the IoT Connector client is notified depends on the underlying protocol. In some cases, like for the MQTT, there is no way to inform the client that the rate limit has been exceeded, else for HTTP-based connectors, the response code could be 429.

In the DPS, by entering the editing page of a thing, and then Cloud tab, you can have evidence of the publishing status, including:

  • the current publishing rate limit, beyond which, published data will be discarded.
    The rate limit is visible only to Organization and Partner users.

  • the publishing status in the last 24 hours.
    In case the rate limit has been exceeded, you will see the number of discarded measures by hour.