共计 1750 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章主要介绍了如何实现 Rocketmq 拉取 pull 消息分页数目测试，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让丸趣 TV 小编带着大家一起了解一下。
一 机器部署
1、机器组成
7 台机器，均为 16G 内存
每台服务器均有 4 个 CPU，2 核
2、运行环境配置
3、刷盘方式
每台机器 master 机器均采用异步刷盘方式
二 性能评测
1、评测目的
测试 pull 消费模式，单次批量拉消息最大条数。
2、评测指标
批量拉取消息最大条数 msgExtSize
自定义配置 最大拉取条数 maxNums
3、评测逻辑
（1）先发送 10000 条消息，等待消息全部发送完毕，然后启动 consumer 端消费消息。
（2）配置 maxNums 的值分别为 1、3、5、8、16、20、24、27、31、32、33、34、35、36、54、80、100，然后对比每次拉取消息的 msgExtSize 条数。
（3）记录每次批量拉取消息的最大条数，即可测试出批量拉消息最大条数。
（4）步骤 3 找出批量拉消息最大条数后，在这个数值前后再设置连续数字，进一步验证此数值。
4、评测过程
（1）第一组：开启 20 个线程，每个线程发送 3000 条数据，总共向 topic 名称为 “pullTest”发送 60W 条消息（消息量越多越好，consumer 端消费速率很快，故发送消息的数据量越多越好，这样以便于看出效果）。
消息发送如下：
设置 maxNums= 1 的消费记录，输出的 msgExtSize=1
设置 maxNums= 3 的消费记录，输出的 msgExtSize=2
设置 maxNums= 5 的消费记录，输出的 msgExtSize=4
设置 maxNums= 8 的消费记录，输出的 msgExtSize=7
设置 maxNums=16 的消费记录，输出的 msgExtSize=15
设置 maxNums=20 的消费记录，输出的 msgExtSize=19
设置 maxNums=24 的消费记录，输出的 msgExtSize=23
设置 maxNums=27 的消费记录，输出的 msgExtSize=26
设置 maxNums=32 的消费记录，输出的 msgExtSize=31
设置 maxNums=36 的消费记录，输出的 msgExtSize=32
设置 maxNums=54 的消费记录，输出的 msgExtSize=32
设置 maxNums=80 的消费记录，输出的 msgExtSize=32
设置 maxNums=100 的消费记录，输出的 msgExtSize=32
分析以上各条件的测试数据可知： 批量拉消息最大条数的条数是 32。
（2）第二组：在拉取消息的最大条数 前后的数字，细粒度的再次测试。
设置 maxNums=33 的消费记录，输出的 msgExtSize=32
设置 maxNums=34 的消费记录，输出的 msgExtSize=32
设置 maxNums=35 的消费记录，输出的 msgExtSize=32
设置 maxNums=31 的消费记录，输出的 msgExtSize=30
进一步分析测试数据，批量拉消息最大条数的条数是 32。
分析结果如下：
自定义最大拉取数
(期望) 批量拉消息最大条数
(实际)1132548716152019242327263130323133323432353236325432803210032
二 评测结果
1、如下测试结论，基于消息存储于内存的场景（而非消息存储于磁盘的场景）。
在 Pull 消费场景下，令 maxA = 自定义最大拉取条数， maxB= 实际批量拉消息最大条数， 则得出如下结论：
（1）若 maxA = 1， 则 maxB = 1
（2）若 maxA = 32, 则 maxB = maxA – 1
（3）若 maxA 32， 则 maxB = 32
2、查阅 RocketMQ 配置文件，如果消息存储于磁盘，则实际批量拉消息最大条数是为 8（并非期望的数值 32），奈何此种测试场景不太好重现，暂未测试，留待后续进一步重现测试。
感谢你能够认真阅读完这篇文章，希望丸趣 TV 小编分享的“如何实现 Rocketmq 拉取 pull 消息分页数目测试”这篇文章对大家有帮助，同时也希望大家多多支持丸趣 TV，关注丸趣 TV 行业资讯频道，更多相关知识等着你来学习!
