Publishing Rate Limit

  • 2 minute(s) read

Servitly receives data from connected products via built-in and external IoT connectors; however, this data flow is limited by a rate limit (points per minute).
This prevents products from publishing too many data points (e.g. firmware bugs).


The 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. 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.

If not redefined in the commercial offer, each environment has specific limitations, and you can verify them in the Environment Types and Limits article.  If you need a higher rate, you must contact the Servitly support.

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.