请求包的大小会影响Redis每秒处理请求数量

🔊博主介绍

🌟我是廖志伟，一名Java开发工程师、Java领域优质创作者、CSDN博客专家、51CTO专家博主、阿里云专家博主、清华大学出版社签约作者、产品软文专业写手、技术文章评审老师、问卷调查设计师、个人社区创始人、开源项目贡献者。🌎跑过十五公里、🚀徒步爬过衡山、🔥有过三个月减肥20斤的经历、是个喜欢躺平的狠人。

📕拥有多年一线研发和团队管理经验，研究过主流框架的底层源码(Spring、SpringBoot、Spring MVC、SpringCould、Mybatis、Dubbo、Zookeeper)，消息中间件底层架构原理(RabbitMQ、RockerMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。

📙有过从0到1的项目高并发项目开发与管理经验，对JVM调优、MySQL调优、Redis调优 、ElasticSearch调优、消息中间件调优、系统架构调优都有着比较全面的实战经验。

📘有过云端搭建服务器环境，自动化部署CI/CD，弹性伸缩扩容服务器（最高200台），了解过秒级部署（阿里云的ACK和华为云的云容器引擎CCE）流程，能独立开发和部署整个后端服务，有过分库分表的实战经验。

🎥经过多年在CSDN创作上千篇文章的经验积累，我已经拥有了不错的写作技巧，与清华大学出版社签下了四本书籍的合约，并将陆续在明年出版。这些书籍包括了基础篇、进阶篇、架构篇的📌《Java项目实战—深入理解大型互联网企业通用技术》📌，以及📚《解密程序员的思维密码–沟通、演讲、思考的实践》📚。具体出版计划会根据实际情况进行调整，希望各位读者朋友能够多多支持！

---

🌾阅读前，快速浏览目录和章节概览可帮助了解文章结构、内容和作者的重点。了解自己希望从中获得什么样的知识或经验是非常重要的。建议在阅读时做笔记、思考问题、自我提问，以加深理解和吸收知识。

💡在这个美好的时刻，本人不再啰嗦废话，现在毫不拖延地进入文章所要讨论的主题。接下来，我将为大家呈现正文内容。

🥤本文内容

压测规划

实施性能评估之前，我们需明确介绍本次测试的环境要素。

设备性能： 选用一台具备1核CPU，内存总量为1GB的阿里云服务器对另一台拥有2核CPU、内存总容量为4GB的Redis服务器进行压力测试。此Redis服务器CPU型号为2.5 GHz主频的Intel® Xeon® E5-2682 v4（Broadwell），以确保测试客户端设备性能不受阻碍。

网络环境： 两台服务器网卡均采用1000M速率，位于同一局域网内，内网带宽为1000M。两台设备的内网IP地址分别为：110.42.239.246（Redis服务器）与139.224.233.121（测试服务器）。

系统环境： 两台服务器均采用CentOS7操作系统，以下两项参数需设定为：

vm.overcommit_memory = 1
net.core.somaxconn = 2048
1
2

Redis相关配置： 主要关注三项配置：

#后代运行 
daemonize yes 
#不开启applend形式的数据持久化能力 
appendfsync no 
#不开启快照能力
save <seconds> <changes>
1
2
3
4
5
6

测试工具： 借助Redis自带的测试工具redis-benchmark进行测量。以下是在测试服务器上执行的指令：

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 100 -P 8 -q
1

让我们分析上述命令中各个参数的含义：

-h 目标Redis服务器网络地址

-p 目标Redis服务器端口

-c 客户端并发长连接数

-n 本次测试所需发起的请求数

-t 测试请求类型

-d 测试请求数据量

-P 启动Pipeline模式，并设置Pipeline通道数量

-q 仅显示"requests per second"结果

以上命令的含义即为，针对110.42.239.246:6379这台Redis发送共计100万次请求，平均使用20个长连接执行，所有请求均为set命令，每条set命令包长100字节，开启8条Pipeline通道传输，仅呈现requests per second结果。

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 100 -P 8 -q

SET: 534759.38 requests per second
1
2
3

客户端长连接数量对性能的影响

我们将进行四项实验，即分别应用一条长连接、五条长连接、十条长连接以及五十条长连接，向大小为100字节的请求发送100万次请求，以比较和观察不同数量的客户端长连接对Redis服务性能产生何种影响。以下是详细信息：

单条长连接实验：

./redis-benchmark -h 110.42.239.246 -p 6379 -c 1 -n 1000000 -t set -d 100 -q SET: 8768.55 requests per second
1

五条长连接实验：

./redis-benchmark -h 110.42.239.246 -p 6379 -c 5 -n 1000000 -t set -d 100 -q SET: 35334.44 requests per second
1

十条长连接实验：

./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 100 -q SET: 52430.14 requests per second
1

五十条长连接实验：

./redis-benchmark -h 110.42.239.246 -p 6379 -c 50 -n 1000000 -t set -d 100 -q SET: 52413.65 requests per second
1

基于上述三个测试用例的实验结果，我们得出以下结论：

仅存在单个持久连接通信时，RPS（每秒处理请求数）约为8700次；

当持久连接数量逐渐增加时，RPS的数值呈现近乎线性的上升趋势；

当持久连接数量达到某个特定数值后，Redis服务器总体的RPS将趋于稳定，稳定在52400左右的范围内；

客户端持久连接的数量对Redis的总体吞吐量具有直接影响，然而，在持久连接数量增长至均衡值后，持久连接数量不再对系统总体吞吐量产生显著影响，该均衡值取决于具体的应用场景，例如网络速度、请求包大小等因素均会产生相应的影响。

请求包大小的影响

请求包的大小无疑会对Redis每秒处理的请求数量产生影响，为了深入了解其具体影响机制，我们进行了多组实验加以观测。

请求包大小为2字节 ：./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 2 -q SET: 52474.16 requests per second CPU平均损耗：42%

请求包大小为1000字节：./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 1000 -q SET: 52430.14 requests per second CPU损耗：48%

请求包大小为1400字节：./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 1400 -q SET: 45396.77 requests per second CPU平均损耗：41%

请求包大小为1500字节：./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 1500 -q SET: 25518.67 requests per second CPU平均损耗：29%

请求包大小为5000字节：./redis-benchmark -h 110.42.239.246 -p 6379 -c 10 -n 1000000 -t set -d 5000 -q SET: 12736.74 requests per second CPU平均损耗：24%

请求包大小为10000字节：./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 10000 -q SET: 6476.81 requests per second CPU平均损耗：18%

根据上述六项实验所揭示的结果，我们可以归纳出如下结论：

当Redis服务器拥有充分的CPU资源支持时，无论是仅有2字节的请求，还是达到1000字节的请求，均不会对Redis的整体处理能力产生显著影响。

当请求体积在1400字节以下时，Redis的性能显示出稳定的特性，然而，当请求体积恰好达到1500字节时，Redis整体性能发生严重下滑。这是因为通常TCP/IP网络的MTU设定为1500字节，一旦测试数据尺寸超过此数字，它就会被划分为多个数据包在网络中传输，从而加剧了性能下降的程度。

当请求体积超过1500之后，Redis的性能呈现出与包裹体增长呈近乎线性关系的下跌趋势。

Pipleline模式对Redis的影响

Redis以同步的请求响应模型作为服务供给的基础，在常规情况下，客户端在接收到Redis的响应之后才会发出第二条请求。在这一过程中，倘若大量的指令同时需要执行，则每个长连接的利用效率并不高，大部分时间都处在等待状态，这种模式下长连接的利用效率有待提高。

Redis提供了一种能够聚合请求和响应的Pipeline模式，其核心思想是将多个指令纳入同一个请求中发送至Redis，然后Redis会依次执行这些命令，在执行过程中，将结果缓存到内存中，且待所有的指令均执行完毕后，将所有指令的执行结果打包在一个响应中返回给客户端。

在特定的场景下，Pipeline模式具有相当大的实用性，例如多个command对相应结果相互独立，亦或者对于结果响应无需立刻获取，此时，Pipeline模式可以胜任这种“批量处理”的任务；此外，在一定程度上，可以显著提升性能，性能提升的主要原因在于TCP连接中减少了“交互往返”的时间。

在三个相对较小的command置于同一个Pipeline请求中时，通常只需一个TCP报文即可发送至服务器端，相较之下，非Pipeline模式则需发送三次，每次都需等待响应返回后方可继续发送，因此在传输与处理效率方面，Pipeline机制表现出明显的优越性。

接下来，我们会进行一项实验以验证具体的效率提升幅度。

命令大小为100字节，不使用pipeline传输

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 100 -q

SET: 52394.43 requests per second

命令大小为100字节，使用pipeline传输，每个请求携带8个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 100 -q -P 8

SET: 495662.97 requests per second

命令包大小为100字节，使用pipeline传输，每个请求携带10个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 100 -q -P 10

SET: 558659.25 requests per second

命令包大小为100字节，使用pipeline传输，每个请求携带11个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 100 -q -P 11

SET: 312940.09 requests per second

命令包大小为100字节，使用pipeline传输，每个请求携带15个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 100 -q -P 15

SET: 452386.34 requests per second

请求包大小为100字节，使用pipeline传输，每个请求携带40个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 5000000 -t set -d 100 -q -P 40

SET: 487519.53 requests per second

请求包大小为200字节，不使用pipeline传输

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 200 -q

SET: 51167.91 requests per second

请求包大小为200字节，使用pipeline传输，每个请求携带4个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 200 -q -P 4

SET: 220288.56 requests per second

请求包大小为200字节，使用pipeline传输，每个请求携带6个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 200 -q -P 6

SET: 161147.36 requests per second

请求包大小为200字节，使用pipeline传输，每个请求携带8个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 2000000 -t set -d 200 -q -P 8

SET: 221361.38 requests per second

请求包大小为3000字节，不使用pipeline传输

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 3000 -q

SET: 21104.17 requests per second

请求包大小为3000字节，使用pipeline传输，每个请求携带8个命令

./redis-benchmark -h 110.42.239.246 -p 6379 -c 20 -n 1000000 -t set -d 3000 -q -P 8

SET: 21713.17 requests per second
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

通过分析上文所阐述的一系列实验数据，我们得出如下观点：

若命令包体较小，pipeine机制对Redis总体性能的提升效果愈加明显，当命令包体为100字节时，Redis的整体性能可实现一个数量级的显著提高；

针对一个pipeine请求的总体规模（命令包大小乘以命令个数），若其恰好与TCP/IP网络的MTU设定相匹配，不易产生碎片请求的情况下，性能最佳，此种状况难以强行追求；

然而，当命令包体增大时，pipeine机制对Redis整体性能的提升并无显著作用。

在命令传输内容相对较少，且各命令之间无依赖关系的情况下，采用pipeine机制可显著提升Redis的整体吞吐量。然而，某些系统可能对可靠性有较高要求，要求每次操作均需立即得知此次操作的执行情况及其数据是否已写入Redis，对于此类系统，pipeine机制或许并不适用。当命令传输的内容较大时（例如大于3k），pipeine机制对性能的提升效果亦不再明显，因此建议此时不宜采用pipeine机制。

📢文章总结

对本篇文章进行总结：

🔔以上就是今天要讲的内容，阅读结束后，反思和总结所学内容，并尝试应用到现实中，有助于深化理解和应用知识。与朋友或同事分享所读内容，讨论细节并获得反馈，也有助于加深对知识的理解和吸收。

🔔如果您需要转载或者搬运这篇文章的话，非常欢迎您私信我哦~

🚀🎉希望各位读者大大多多支持用心写文章的博主，现在时代变了，🚀🎉 信息爆炸，酒香也怕巷子深🔥，博主真的需要大家的帮助才能在这片海洋中继续发光发热🎨，所以，🏃💨赶紧动动你的小手，点波关注❤️，点波赞👍，点波收藏⭐，甚至点波评论✍️，都是对博主最好的支持和鼓励！

• 💂 博客主页： 我是廖志伟
• 👉开源项目：java_wxid
• 🌥 哔哩哔哩：我是廖志伟
• 🎏个人社区：幕后大佬
• 🔖个人微信号： SeniorRD
• 🎉微信号二维码：

📥博主目标

• 🍋程序开发这条路不能停，停下来容易被淘汰掉，吃不了自律的苦，就要受平庸的罪，持续的能力才能带来持续的自信。我本是一个很普通的程序员，放在人堆里，除了与生俱来的盛世美颜，就剩180的大高个了，就是我这样的一个人，默默写博文也有好多年了。
• 📺有句老话说的好，牛逼之前都是傻逼式的坚持，希望自己可以通过大量的作品、时间的积累、个人魅力、运气、时机，可以打造属于自己的技术影响力。
• 💥内心起伏不定，我时而激动，时而沉思。我希望自己能成为一个综合性人才，具备技术、业务和管理方面的精湛技能。我想成为产品架构路线的总设计师，团队的指挥者，技术团队的中流砥柱，企业战略和资本规划的实战专家。
• 🎉这个目标的实现需要不懈的努力和持续的成长，但我必须努力追求。因为我知道，只有成为这样的人才，我才能在职业生涯中不断前进并为企业的发展带来真正的价值。在这个不断变化的时代，我们必须随时准备好迎接挑战，不断学习和探索新的领域，才能不断地向前推进。我坚信，只要我不断努力，我一定会达到自己的目标。

🔔有需要对自己进行综合性评估，进行职业方向规划，我可以让技术大牛帮你模拟面试、针对性的指导、传授面试技巧、简历优化、进行技术问题答疑等服务。

可访问：https://java_wxid.gitee.io/tojson/