This topic describes the limits and specifications for certain metrics in ApsaraMQ for MQTT. When you use ApsaraMQ for MQTT, do not exceed these limits to prevent program exceptions. The following tables provide more details about these limits.
If you purchase a Platinum Edition instance of ApsaraMQ for MQTT, you can customize certain metrics. These metrics are marked in the tables below. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918.
Instance limits
Limitations | Limit | Description |
Instance name |
| You cannot specify a custom name when you create an instance. By default, the name of a new instance is the same as its instance ID. You can modify the name in the ApsaraMQ for MQTT console. |
Messaging TPS of a single instance | Throttling is based on your purchased specifications. If the messaging transactions per second (TPS) of ApsaraMQ for MQTT exceeds the limit of your specifications, issues such as disconnections, response timeouts, and message discards may occur on clients. This applies to clients such as open source MQTT clients and cloud software development kits (SDKs). In this case, reliable message delivery is not guaranteed. | A single MQTT client typically does not handle a large volume of messages, and some SDKs are not designed for high throughput. The messaging TPS for a single MQTT client should not exceed 20. If you require a higher message volume for a server-side application, consider using an ApsaraMQ for RocketMQ client. |
Number of online connections for a single instance | Throttling is based on your purchased specifications. If the number of connections exceeds the limit, new connection requests may be rejected. | By default, ApsaraMQ for MQTT provides monitoring alarms for the number of online connections. You can adjust the monitoring threshold as needed. |
Number of subscription relationships for a single instance | If the number of subscriptions exceeds the specification limit, new subscriptions may fail. The corresponding client connections may be disconnected, and the integrity of the subscription relationships cannot be guaranteed. | By default, ApsaraMQ for MQTT provides monitoring alarms for the number of subscription relationships. You can adjust the monitoring threshold as needed. |
IP address that corresponds to the instance endpoint | None | This IP address can change at any time. Do not hardcode the IP address. The ApsaraMQ for MQTT product team is not responsible for issues that occur in the following situations:
|
Topic limits
Restrictions | Limit | Description |
Topic name |
| When you send and receive messages using ApsaraMQ for MQTT, the topic length must be within the specified limits. Otherwise, you cannot send or subscribe to messages. |
Number of parent topics for a single instance | 25 | If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. |
Cross-region use of topics | Not supported | If you configure rules for data exchange between ApsaraMQ for MQTT and ApsaraMQ for RocketMQ, the related resources must be in the same region. |
Client limits
Limits | Limit | Description |
Client ID |
| When you send and receive messages using ApsaraMQ for MQTT, the Client ID must not exceed the length limit. Otherwise, the connection is disconnected. |
Group ID |
| When you send and receive messages using ApsaraMQ for MQTT, the Group ID length must be within the specified limits. Otherwise, you cannot send or subscribe to messages. |
Device ID |
| When you send and receive messages using ApsaraMQ for MQTT, the Client ID must not exceed the length limit. Otherwise, the connection is disconnected. |
Number of topics a client can subscribe to | 30 | Each client can subscribe to a maximum of 30 topics simultaneously. If this limit is exceeded, new subscription requests fail. Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. When you calculate the number of subscribed topics, a subscription that contains a wildcard character counts as one subscription. Subscriptions to different child topics under the same parent topic are counted as separate subscriptions. For example, A/# is counted as one subscription, and A/# and A/a1/# are counted as two subscriptions. |
Number of wildcard subscription relationships | A maximum of 100 wildcard subscription relationships are allowed for each parent topic. | The service limits the number of active wildcard subscription relationships for each parent topic. If this limit is exceeded, the service loads only 100 relationships. This may cause some subscribed clients to not receive messages. You must strictly control the number of relationships. For example, for the same parent topic A, subscriptions to A/#, A/a1/#, and A/a2/# are counted as three subscription relationships. |
Maximum heartbeat interval | 8 minutes | When sending and receiving messages with ApsaraMQ for MQTT, the maximum heartbeat interval is 8 minutes. |
Limits on data flow and client status rules
Limits | Limit | Description |
Number of rules per instance | 100 | If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. |
Rule deduplication | For the same internal resource, you can create only one rule of each type. | For example, you can create only one online/offline notification rule for a Group ID, and only one data inbound rule and one data outbound rule for an MQTT topic. |
Region limit | You cannot create rules across regions. The instances of the data source and data destination for a rule must be in the same region. | For example, if you create a data outbound rule and the source ApsaraMQ for MQTT instance is in the China (Hangzhou) region, you can select only an ApsaraMQ for RocketMQ instance in the China (Hangzhou) region as the data destination. |
ApsaraMQ for MQTT instance version | Only ApsaraMQ for MQTT instances of version 3.x.x support this feature. | Only ApsaraMQ for MQTT instances of version 3.x.x can be purchased. |
ApsaraMQ for RocketMQ instance version | Only 4.0 series instances are supported. | When ApsaraMQ for MQTT and ApsaraMQ for RocketMQ exchange data through data inbound or data outbound rules, only ApsaraMQ for RocketMQ 4.0 series instances support these rules. 5.0 series instances are not supported. |
Message sending and receiving limits
ApsaraMQ for MQTT does not support last will and testament messages or retained messages.
Limits | Limit | Description |
Message size | 64 KB | The message payload must not exceed this limit. Otherwise, the message is discarded. Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. |
Message retention period | 3 days | ApsaraMQ for MQTT retains offline messages only when QoS=1 and cleanSession=false. The messages are retained for a maximum of 3 days and are automatically deleted by automatic scrolling after this period. For more information about Quality of Service (QoS) and cleanSession, see Glossary. Platinum Edition instances support customization. To request a customization, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. |
QoS and cleanSession |
| When you send and receive messages using ApsaraMQ for MQTT:
|
Token validity period | 30 days | When you call the operation to apply for a token, if the value of ExpireTime is greater than 30 days, the operation still succeeds and returns a token without an error. However, the actual validity period is still 30 days. |
Offline message visibility time | 10 seconds | After the service pushes a message for the first time, it must wait for a timeout or failure to confirm whether the message is converted to an offline message. The corresponding latency is typically 5 to 10 seconds. |
Number of stored offline messages | 1 million | The service limits the number of offline messages stored for each instance. If this limit is exceeded, the service starts to clear messages from the earliest ones. Therefore, use the persistence subscription pattern reasonably to avoid generating too many useless offline messages. If the default limit does not meet your requirements, contact ApsaraMQ for MQTT technical support in DingTalk group 116015007918. |
Number of message push retries |
| The maximum number of times the ApsaraMQ for MQTT service retries pushing a message when the consumer fails to receive the message or consumption fails. |
Cloud API limits
For information about the queries per second (QPS) limits on cloud API calls, see QPS limits.