性能测试和容量评估是保证系统整体稳定性的一个基础保证手段，但是如何实施一场有效压测并不是一个简单的事情，我们建议采用以下压测方案，进行压测前，首先应该结合业务场景明确本次压测的目的，然后确定压测具体方案，包括压测对象，压测场景模拟，工具选择以及应该关注哪些指标等，最后分析压测是否达到预期和明确购买合适的规格。
明确压测目的
如上图所示，针对 RocketMQ 的业务场景，一般关注压测发送消息还是压测消费。
如果压测发送消息，主要关注发送速率，耗时和成功率，以及触发峰值限流后应用的表现。
如果压测消费消息，主要关注消费速率，耗时和成功率，失败后的重试策略，以及堆积消息延迟对业务的影响。
分析压测对象
压测发送消息的场景，主要压测对象为 RocketMQ 实例，需要关注 RocketMQ 实例的发送耗时和成功率，以 RocketMQ 5.x 实例为例，实例默认都会开启分布式限流，防止涌入过大流量导致集群被压垮，所以关注限流对业务的影响。
压测消费消息的场景，主要压测对象为下游的消费者应用，需要关注业务下游的消费消息的能力，主要指标是消费处理耗时和消费并发线程数，是否消费超时，是否有异常导致的重试，和是否产生消息堆积。
模拟压测场景
针对发送消息的场景，通常两种方式，第一种可以使用 Apache RocketMQ 开源代码自带的压测脚本来制造压测流量，第二种也可以也入口录制或模拟业务流量，通过业务逻辑代码使用生产者应用进行全链路压测。
通常，我们建议先通过开源代码自带的压测脚本来快速的摸底进行压测，快速拿到 RocketMQ 实例的一些基准指标，做到心里有底，确保RocketMQ 实例本身是达标的，然后再结合业务模型，通过模拟压测业务流量，设置合理的并发数，确保最终在压测结果可以满足业务的需求。
针对消费消息的场景，通常也有两种方式，第一种可以使用 Apache RocketMQ 开源代码自带的压测脚本，订阅压测的 topic，默认收到消息后立即确认消息，来确认 RocketMQ 实例提供的消费能力是足够的。第二种也是通过全链路的压测，由上游消息发送方发送符合消费方业务代码要求的消息格式，确保消费业务代码可以被压测覆盖到，甚至将压测流量进一步传导到下游。
分析压测指标
发送指标
关注发送速率，发送耗时和发送成功率，以及是否触发限流，以及限流后对业务的影响或着消息重试策略。
消费指标
关注消费速率，消费业务耗时，消费延迟和消费成功率，以及消息堆积和延迟对业务的影响。
常见问题分析
1.如何解决发送速率压不上去？
决定发送速率的核心因素有两个，一个是发送耗时，一个是发送并发度，假如平均发送耗时是 5ms，并发度是 1 的话，则发送速率是 200 TPS；所以如果遇到压测目标不达标的时候，首先确认一下发送耗时，比如是不是网络走了公网，或者经过了代理，到时发送耗时偏高； 如果发送耗时符合预期，则重点排查并发度是否满足，发送方的并行执行的线程数量是否足够，发送方的节点的负载是否正常，更上层是否有锁等因素影响。
2.如何高效模拟流量的压测下游业务方？
经常为了达到好的压测效果，需要压测流量尽可能的接近真实的业务，为了模拟流量，除了全链路压测以外，还可以通过重置消费位点的方式，重放历史消息，来给下游业务方高效的制造流量，这样就不需要上游业务来反复的制造发送流量。
3.如何分析触发限流的原因？
因为 RocketMQ 5.x 实例默认开启了限流，如果压测触发了限流，重点分析以下几个原因：
1. 存在“微突发”的场景，比如我们的监控是分钟级粒度的监控，可能所有的流量集中在前 1 秒发起，实际我们限流令牌窗口是 10秒更新一次窗口，这样就会导致分钟级监控看没有超限流值，实际上10 秒粒度却会被限流。
2. 消息体过大，因为限流是按照 4KB 一条消息折算，比如 100KB 的消息，将会折算为 25 条消息，进行限流，所以限流值和生产消息条数并不是一对一的。
3. 限流比例调整不合适，我们提供了可以调整发送和消费限流配额比例，默认为 5:5 ，最多可以调整为 2:8 或者 8:2，所以如果触发了限流，也要检查一下配置的限流配额比例是否合理。
