Throttling can be triggered for a single ApsaraMQ for RabbitMQ instance based on the peak transactions per second (TPS) of the instance. This topic describes the throttling rules for a ApsaraMQ for RabbitMQ instance, 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 a ApsaraMQ for RabbitMQ instance exceeds the TPS threshold value that is specified when the ApsaraMQ for RabbitMQ instance is purchased, throttling is triggered for the instance.
- 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 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
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 provides the following methods that you can use to query the peak TPS of an instance based on a granularity of seconds:
Method | Description | Time granularity | Resource level |
---|---|---|---|
(Recommended)Query the peak TPS of an instance and configure an alert rule by using CloudMonitor | Benefits:
| 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 |
| Peak TPS at the second level |
|
Query the peak TPS by using Log Service |
| 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
The delayed message is an advanced message type in ApsaraMQ for RabbitMQ. One API call to send or receive a delayed message is counted as five API calls to send or receive a normal message.
For example, if delayed messages are published 10 times per second, the TPS is calculated based on the following formula: 10 times per second × 5 = 50 times per second.