当前位置:网站首页>Two benchmark performance test methods of redis
Two benchmark performance test methods of redis
2022-04-21 23:28:00 【Bloody Remilia】
Redis The purpose of benchmark performance test is to measure under different software and hardware configurations Redis Basic performance , To infer from Redis Is it slowing down . To put it more bluntly , If there are two machines AB, machine A The performance of the machine is only B Half of , When the machine B Of Redis Response time is higher than 100 millisecond , We think this is a slow response , But machines A You can't use a machine B Response time-consuming criteria , Because their basic performance is not the same , Here are two ways of benchmark performance testing .( The configuration I use is :Ubuntu Server 20.04、R9-5900X ( Distribute 2 A virtual core )、8G Memory 、120G NVME Solid state disk ,redis edition 6.2.6)
Mode one :redis-cli --intrinsic-latency
from Redis Of 2.8.7 Version start ,redis-cli The command can append –intrinsic-latency Options , This option can be used to monitor and count Redis The maximum delay of , We can take this delay as Redis The benchmark performance of .–intrinsic-latency Option needs to specify the duration , For example, below I specify 120 second :

Mode two :redis-benchmark
redis-benchmark yes redis Built in performance testing tools , It is suitable for use when the business volume is known ,redis-benchmark Official documents of Click here
I simulate here 500 Simultaneous requests from multiple clients redis Of get And set operation , A total of requests 10 Ten thousand times
redis-benchmark -t set,get -c 500 -n 100000
====== SET ======
100000 requests completed in 0.40 seconds
500 parallel clients
3 bytes payload
keep alive: 1
host configuration "save": 3600 1 300 100 60 10000
host configuration "appendonly": no
multi-thread: no
Latency by percentile distribution: # Delay as a percentage
0.000% <= 0.399 milliseconds (cumulative count 1)
50.000% <= 1.007 milliseconds (cumulative count 51601)
75.000% <= 1.047 milliseconds (cumulative count 78236)
87.500% <= 1.095 milliseconds (cumulative count 88069)
93.750% <= 1.191 milliseconds (cumulative count 93943)
96.875% <= 1.375 milliseconds (cumulative count 96903)
98.438% <= 1.687 milliseconds (cumulative count 98444)
99.219% <= 1.863 milliseconds (cumulative count 99237)
99.609% <= 1.991 milliseconds (cumulative count 99617)
99.805% <= 2.103 milliseconds (cumulative count 99812)
99.902% <= 2.199 milliseconds (cumulative count 99906)
99.951% <= 2.319 milliseconds (cumulative count 99952)
99.976% <= 2.431 milliseconds (cumulative count 99977)
99.988% <= 2.487 milliseconds (cumulative count 99988)
99.994% <= 2.527 milliseconds (cumulative count 99994)
99.997% <= 2.543 milliseconds (cumulative count 99998)
99.998% <= 2.551 milliseconds (cumulative count 100000)
100.000% <= 2.551 milliseconds (cumulative count 100000)
Cumulative distribution of latencies: # Cumulative distribution of delay
0.000% <= 0.103 milliseconds (cumulative count 0)
0.004% <= 0.407 milliseconds (cumulative count 4)
0.042% <= 0.503 milliseconds (cumulative count 42)
0.086% <= 0.607 milliseconds (cumulative count 86)
0.208% <= 0.703 milliseconds (cumulative count 208)
0.514% <= 0.807 milliseconds (cumulative count 514)
0.999% <= 0.903 milliseconds (cumulative count 999)
51.601% <= 1.007 milliseconds (cumulative count 51601)
88.828% <= 1.103 milliseconds (cumulative count 88828)
94.390% <= 1.207 milliseconds (cumulative count 94390)
96.115% <= 1.303 milliseconds (cumulative count 96115)
97.092% <= 1.407 milliseconds (cumulative count 97092)
97.523% <= 1.503 milliseconds (cumulative count 97523)
98.060% <= 1.607 milliseconds (cumulative count 98060)
98.523% <= 1.703 milliseconds (cumulative count 98523)
99.008% <= 1.807 milliseconds (cumulative count 99008)
99.379% <= 1.903 milliseconds (cumulative count 99379)
99.658% <= 2.007 milliseconds (cumulative count 99658)
99.812% <= 2.103 milliseconds (cumulative count 99812)
100.000% <= 3.103 milliseconds (cumulative count 100000)
Summary:
throughput summary: 248756.22 requests per second # Pass per second 248756 A request
latency summary (msec):
avg min p50 p95 p99 max
1.034 0.392 1.007 1.239 1.807 2.551
====== GET ======
100000 requests completed in 0.41 seconds
500 parallel clients
3 bytes payload
keep alive: 1
host configuration "save": 3600 1 300 100 60 10000
host configuration "appendonly": no
multi-thread: no
Latency by percentile distribution:
0.000% <= 0.447 milliseconds (cumulative count 1)
50.000% <= 1.031 milliseconds (cumulative count 51602)
75.000% <= 1.071 milliseconds (cumulative count 79450)
87.500% <= 1.103 milliseconds (cumulative count 87789)
93.750% <= 1.199 milliseconds (cumulative count 93971)
96.875% <= 1.303 milliseconds (cumulative count 96942)
98.438% <= 1.583 milliseconds (cumulative count 98462)
99.219% <= 1.847 milliseconds (cumulative count 99234)
99.609% <= 2.079 milliseconds (cumulative count 99615)
99.805% <= 2.319 milliseconds (cumulative count 99806)
99.902% <= 2.527 milliseconds (cumulative count 99904)
99.951% <= 2.887 milliseconds (cumulative count 99952)
99.976% <= 3.167 milliseconds (cumulative count 99976)
99.988% <= 3.287 milliseconds (cumulative count 99988)
99.994% <= 3.335 milliseconds (cumulative count 99994)
99.997% <= 3.359 milliseconds (cumulative count 99997)
99.998% <= 3.375 milliseconds (cumulative count 100000)
100.000% <= 3.375 milliseconds (cumulative count 100000)
Cumulative distribution of latencies:
0.000% <= 0.103 milliseconds (cumulative count 0)
0.016% <= 0.503 milliseconds (cumulative count 16)
0.061% <= 0.607 milliseconds (cumulative count 61)
0.125% <= 0.703 milliseconds (cumulative count 125)
0.296% <= 0.807 milliseconds (cumulative count 296)
0.647% <= 0.903 milliseconds (cumulative count 647)
38.290% <= 1.007 milliseconds (cumulative count 38290)
87.789% <= 1.103 milliseconds (cumulative count 87789)
94.316% <= 1.207 milliseconds (cumulative count 94316)
96.942% <= 1.303 milliseconds (cumulative count 96942)
97.550% <= 1.407 milliseconds (cumulative count 97550)
97.959% <= 1.503 milliseconds (cumulative count 97959)
98.535% <= 1.607 milliseconds (cumulative count 98535)
98.837% <= 1.703 milliseconds (cumulative count 98837)
99.117% <= 1.807 milliseconds (cumulative count 99117)
99.348% <= 1.903 milliseconds (cumulative count 99348)
99.521% <= 2.007 milliseconds (cumulative count 99521)
99.641% <= 2.103 milliseconds (cumulative count 99641)
99.970% <= 3.103 milliseconds (cumulative count 99970)
100.000% <= 4.103 milliseconds (cumulative count 100000)
Summary:
throughput summary: 243902.44 requests per second
latency summary (msec):
avg min p50 p95 p99 max
1.051 0.440 1.031 1.231 1.767 3.375
版权声明
本文为[Bloody Remilia]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/04/202204212007504981.html
边栏推荐
- Changsha good man
- TextView 倾斜属性
- golang力扣leetcode 479.最大回文数乘积
- 雲原生架構下的微服務選型和演進
- MySQL pit father Guide_ sql_ Mode = "only_full_group_by"
- Self made whole person computer applet
- Golang force buckle leetcode 385 Mini parser
- 87 R k-means,层次聚类,EM聚类的实现
- Why don't MySQL use select * as query criteria? (continuously updated)
- Selection and evolution of microservices under cloud native architecture
猜你喜欢

Self made webserver from scratch (XVI) -- learn a new tool cmake to automatically write makefile and sort out source files by categories. Feel happy

音视频基本概念和FFmpeg的简单入门

Simple and easy to collect navigation website source code

云原生架构下的微服务选型和演进

手机APP游戏/软件/资源下载站/软件盒子源码

Ijcai2022 employment results released! The acceptance rate is 15%. Did you win?

痞子衡嵌入式:聊聊系统看门狗WDOG1在i.MXRT1xxx系统启动中的应用及影响

Sélection et évolution des microservices dans l'architecture native du cloud

雲原生架構下的微服務選型和演進

自定义登录成功处理
随机推荐
2022-04-22日报:基于Transformer的新型人脸属性编辑框架TransEditor
Swoole high performance in memory database use and configuration tutorial
SWOOLE高性能内存数据库的使用和配置教程
golang力扣leetcode 2245.转角路径的乘积中最多能有几个尾随零
2022/4/21
[H.264] simple encoder and SPS
Chapter 2 installation of MySQL database
入参有汉字,报错500,服务器内部错误
NN in pytoch Brief introduction to adaptive avgpool2d (output_size)
Golang force buckle leetcode 388 The longest absolute path of the file
【acwing】1125. Cattle travel * * * (Floyd)
红星美凯龙阵痛:“挥刀“降杠杆、净利率腰斩
MySQL problem solving_ Multi table joint query_ The operator wants to calculate the average answer volume of users from different schools and different difficulties who participated in the answer. Ple
Golang force buckle leetcode 385 Mini parser
手机APP游戏/软件/资源下载站/软件盒子源码
【H.264】SPS 计算帧率方法
341-Linux 连接数据库
GIC spec之ITS和LPI中断5
golang力扣leetcode 388.文件的最长绝对路径
通过点击导入的文件或点击组件进入对应的组件页面进行编辑