Best practices for instance throttling - ApsaraMQ for RabbitMQ

Throttling can be triggered for an ApsaraMQ for RabbitMQ instance based on the peak transactions per second (TPS) of the instance. This topic describes the throttling rules for ApsaraMQ for RabbitMQ instances, the operations performed by the consumer and producer after throttling is triggered, and the best practices that you can use for throttling.

Operations performed by the consumer and producer after throttling is triggered

If the peak TPS of an ApsaraMQ for RabbitMQ instance exceeds the TPS threshold value that is specified when you purchase the ApsaraMQ for RabbitMQ instance, throttling is triggered for the instance.

The following operations are performed after throttling is triggered:

The ApsaraMQ for RabbitMQ broker returns an error code and an error message.
The ApsaraMQ for RabbitMQ broker closes the channel of the current request. You can detect exceptions in the code and reopen the channel.

The following section describes the error code and error message:

Error code: reply-code=530
Error message: reply-text=denied for too many requests

The following sample code provides an example of an error stack of the client in Java:

Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>
(reply-code=530, reply-text=denied for too many requests, ReqId:5FB4C999314635F952FCBFF6, ErrorHelp[dstQueue=XXX_test_queue,
srcExchange=Producer.ExchangeName,bindingKey=XXX_test_bk, http://mrw.so/6rNqO8], class-id=50, method-id=20)
    at com.rabbitmq.client.impl.ChannelN.asyncShutdown(ChannelN.java:516)
    at com.rabbitmq.client.impl.ChannelN.processAsync(ChannelN.java:346)
    at com.rabbitmq.client.impl.AMQChannel.handleCompleteInboundCommand(AMQChannel.java:182)
    at com.rabbitmq.client.impl.AMQChannel.handleFrame(AMQChannel.java:114)
    at com.rabbitmq.client.impl.AMQConnection.readFrame(AMQConnection.java:672)
    at com.rabbitmq.client.impl.AMQConnection.access$300(AMQConnection.java:48)
    at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:599)
    at java.lang.Thread.run(Thread.java:748)

Query the peak TPS of an instance

You can query the actual peak TPS of an instance to understand the traffic fluctuation and peak traffic of your service and determine whether the current instance specification meets your business requirements.

ApsaraMQ for RabbitMQ allows you to use the following methods to query the peak TPS of an instance:

Method	Description	Time granularity	Resource level
(Recommended)Query the peak TPS of an instance and configure an alert rule by using CloudMonitor	Benefits: You can use this query method to query the changes of peak TPS in the previous 14 days. This query method helps you identify exceptions in an efficient manner. You can use the instance peak TPS as a metric to configure an alert rule. You are not charged when you use this query method.	Peak TPS at the minute level The peak TPS of an instance during a 1-minute statistical period	Peak TPS of an instance
(Recommended)Query the peak TPS of an instance on the instance details page	Benefits: You can use this query method to query the peak TPS at the second level. This query method helps you identify exceptions in an accurate manner. You can query the peak TPS of a specific API operation. You are not charged when you use this query method. Usage notes: To prevent excessively long query results, only the query result for the previous 10 minutes is returned.	Peak TPS at the second level	Peak TPS of an instance Peak TPS of a specific API operation
Query the peak TPS by using Log Service	Benefits: You can use Log Service statements to query the peak TPS of an instance. This query method helps you identify exceptions in complex business scenarios. Usage notes: Compared with the preceding two query methods, this query method is more complicated and the query result is not easy to understand. You are charged when you use Log Service. For information about the pricing of Log Service, see Billable items.	Peak TPS at the second level	Peak TPS of an instance

Rules based on which the TPS of an instance is calculated

If you call one of the following operations once, one TPS is counted.

ConnectionOpen and ChannelOpen
QueueDeclare, QueueDelete, QueueBind, and QueueUnbind
ExchangeDeclare and ExchangeDelete
ExchangeBind and ExchangeUnBind
SendMessage, BasicConsume, BasicGet, BasicAck, BasicReject, BasicNack, and BasicRecover

Delayed messages are a type of advance-featured messages provided by ApsaraMQ for RabbitMQ. The number of API calls that are initiated to send and receive delayed messages is five times the number of API calls that are initiated to send and receive normal messages. Therefore, the peak TPS fee of delayed messages is five times the peak TPS fee of normal messages.
For example, if you send two delayed messages and receive three delayed messages within 1 second, the total number of API calls is 25. The number of API calls is calculated by using the following formula: 2 × 5 + 3 × 5 = 25.
When you count the number of API calls to the SendMessage operation, the actual value is the number of queues to which messages are stored after the messages are routed.
For example, if you send one message to an exchange of the Fanout type and save the message to 10 queues, the number of API calls to the SendMessage operation is counted as 10.