This topic describes the limits for metrics in ApsaraMQ for MQTT. To prevent program exceptions, you must set the metrics to values within limits when you use ApsaraMQ for MQTT. The table in the following section describes the limits.
If you use a ApsaraMQ for MQTT Enterprise Platinum Edition instance, you can specify custom values for specific metrics in the following table based on your business requirements. To specify custom values for the metrics, contact ApsaraMQ for MQTT technical support.
| Metric | Limit | Description |
|---|---|---|
| Topic name length | 64 characters | When you use ApsaraMQ for MQTT to send and receive messages, the length of a topic name cannot exceed 64 characters. Otherwise, you cannot send or receive messages. |
| Use of topics across regions | None | The topic of a ApsaraMQ for MQTT instance must reside in the same region as the topic of a backend message persistence instance, such as a ApsaraMQ for RocketMQ instance, to which the Message Queue for MQTT instance is bound. |
| Characters allowed in a topic name and a client ID | Digits, letters, hyphens (-), and underscores (_) | A topic name or a client ID in ApsaraMQ for MQTT cannot contain non-conventional characters such as slashes (/), colons (:), commas (,), and percent signs (%). If the topic name or client ID contains non-conventional characters, client connection may fail and messages may not be sent or received. |
| Length of a client ID | 64 characters | When you use ApsaraMQ for MQTT to send and receive messages, the client ID cannot exceed 64 characters in length. Otherwise, the client may be disconnected. |
| Message size | 64 KB | A message cannot exceed 64 KB in size. Otherwise, the message is discarded. You can specify a custom value for this metric in an Enterprise Platinum Edition instance. |
| Message retention period | Three days | Offline messages can be retained for up to three days only when the QoS parameter is set to 1 and the cleanSession parameter is set to false. After three days, the offline messages are automatically deleted. You can specify a custom value for this metric in an Enterprise Platinum Edition instance. |
| Messaging transactions per second (TPS) | The limit varies based on the instance specification. |
|
| Number of connected clients | The limit varies based on the instance specification. | For a subscription instance, throttling is imposed based on the purchased specification. Connection stability cannot be ensured if the upper limit that is specified in the instance specification is exceeded. For a pay-as-you-go instance, throttling is not imposed. By default, the monitoring and alerting feature is enabled. We recommend that you specify monitoring and alerting thresholds based on your business requirements. |
| Number of subscriptions | The limit varies based on the instance specification. | For a subscription instance, throttling is imposed based on the purchased specification. The integrity of subscriptions cannot be ensured if the upper limit that is specified in the instance specification is exceeded. For a pay-as-you-go instance, throttling is not imposed. By default, the monitoring and alerting feature is enabled. We recommend that you specify monitoring and alerting thresholds based on your business requirements. |
| Number of topics to which a single Message Queue for MQTT client can subscribe | 30 | Each Message Queue for MQTT client can subscribe to up to 30 topics when ApsaraMQ for MQTT is used to send and receive messages. New subscriptions cannot be added if the limit is exceeded. You can specify a custom value for this metric in an Enterprise Platinum Edition instance. |
| QoS and cleanSession configurations | The cleanSession parameter cannot be set to false when the QoS parameter is set to 2. | A ApsaraMQ for MQTT broker does not support subscriptions when the QoS parameter is set to 2 and the cleanSession parameter is set to false. To receive offline messages, set the QoS parameter to 1 and the cleanSession parameter to false. |
| Validity period of a token | 30 Days | The validity period of a token is 30 days. When you call the ApplyToken operation to apply for a token and the ExpireTime parameter is set to a value greater than 30, a token is returned and no error is reported, but the token is valid for only 30 days. |
| Order of messages | Messages are sent in the same order as they are produced. | When you use ApsaraMQ for MQTT to send and receive messages, only the order for sending messages is ensured. If you want to consume messages in order, you must use ApsaraMQ for RocketMQ to receive messages over TCP. |
| Waiting period for offline messages | 10 seconds | The first time a Message Queue for MQTT broker pushes a message, the broker can determine whether the message is converted to an offline message only after the message times out or fails. The waiting period ranges from 5 seconds to 10 seconds. |
| Number of stored offline messages | 1,000,000 | The Message Queue for MQTT broker of an instance limits the number of offline messages that are stored on the broker. If the upper limit is exceeded, the Message Queue for MQTT broker deletes the earliest stored offline messages. To avoid an excessive number of offline messages, configure the cleanSession parameter based on your business requirements when you subscribe to topics. If the default maximum value does not meet your business requirements, contact ApsaraMQ for MQTT technical support. |
| Number of subscriptions that contain wildcards | Each parent topic supports up to 100 subscriptions that contain wildcards. | The Message Queue for MQTT broker supports a limited number of active subscriptions that contain wildcards for each parent topic. When the maximum value is exceeded, the Message Queue for MQTT broker loads only 100 subscriptions. As a result, some subscribers may fail to receive messages. We recommend that you strictly control the number of subscriptions that contain wildcards. |
| IP address of the endpoint for the domain name of ApsaraMQ for MQTT | None | The IP address may unexpectedly change. Do not assume that the IP address is fixed. The ApsaraMQ for MQTT technical team is not liable for faults and direct or indirect losses in the following scenarios:
|