How Cumulocity manages the performance of your tenant

Follow

Cumulocity includes various mechanisms to manage the performance across all customers using Cumulocity and to protect individual customers from so-called "noisy neighbours". "Noisy neighbours" are other Cumulocity customers that consume excessive resources on the Cumulocity systems. 

A key mechanism is to limit the number of requests that devices, systems and users of a customer can send to their Cumulocity account. If the number of requests to a customer's account temporarily exceeds the limit, further requests are delayed and processed more slowly. If the number of requests durably exceeds the limit, further requests are dropped.

Technically, an HTTP request will return the status code 429 ("Too many requests"). An MQTT connection will be dropped.

Trial customers are currently provisioned with a low limit on their request rate. It is not possible to run larger production loads on trial tenants. Production customers are provisioned with enough capacity to run their production loads even in case temporary overcapacity is required.

If you forward data to another tenant using the data broker feature of Cumulocity, and that other tenant does not have enough capacity to accept the data, you will see an alarm in your account with the text "Data broker processing is currently overloaded and may stop forwarding your data". In that case, please contact support to increase the processing capacity on the receiving end. 

Similar, the real-time event processing engines are limited in capacity. If you forward more data than the engine can process, you will receive an alarm "Real-time event processing is currently overloaded...". Again, please contact support to provision a dedicated or larger engine instance.

If you would like to catch these alarms using a smart rule or other specific processing, their alarm types are "c8y_BrokerTaskRejected" and "c8y_CepTaskRejected".

 

Have more questions? Submit a request

Comments