redisc测试 redis基准测试

转载

mob64ca13f96cda 2024-01-22 20:32:27

文章标签 redisc测试 Redis redis MySQL 文章分类 Redis 数据库

1. 概述
2. 性能指标
3. 测试工具
4. redis-benchmark

4.1 测试环境
4.2 安装工具
4.3 使用指南
4.4 快速测试
4.5 精简测试
4.6 pipeline 测试
4.7 随机 KEY 测试

1. 概述

当我们希望提高性能的使用，往往想到的是异步、缓存这个两种手段。

前者，例如说内存队列（例如说 JDK Queue、Disruptor 等）、分布式队列（例如说 RabbitMQ、RocketMQ、Kafka），更多适合写操作。
后者，例如说内存缓存（例如说 JDK Map、EhCache 等）、分布式缓存（例如说 Redis、Memcached 等），更适合读操作。

不过，本文我们不会去聊上述所有的手段或是框架、中间件，而是聚焦本文的主角 Redis 。

日常中，我们经常能在公司、论坛、技术群里看到如下一段对话：

甲：我们的 MySQL 读取很慢啊，有什么办法解决啊？
乙：上缓存啊，Redis 额。

那么，为什么上 Redis 就一般能解决读的问题呢？为了避免将问题复杂化，我们直接看 Redis 和 MySQL 的性能对比。还是老样子，我们来对比阿里云的 MySQL 性能规格和 Redis 性能规格：

1C 1GB 配置

Redis 1C 1GB 主从版，提供 80000 QPS
MySQL 1C 1GB 通用型，提供 465 QPS
相差 172 倍左右的性能

16C 128G 配置

Redis 16C 128G 集群版（单副本），提供 1280000 QPS
MySQL 16C 128G 独享版，提供 48102 QPS
相差 26 倍左右的性能

当然，两者测试的方式，有一定差异，这里仅仅作为一个量级上的对比。

在开始基准测试之前，我们再来看看 Redis 大体的性能规格，从各大云厂商提供的 Redis 云服务。

阿里云 Redis ：https://help.aliyun.com/document_detail/26350.html
华为云 Redis ：暂未找到性能规格
腾讯云 Redis ：https://cloud.tencent.com/document/product/239/17952
百度云 Redis ：暂未找到性能规格
UCloud Redis ：https://docs.ucloud.cn/database/uredis/test 只提供测试方法，不提供性能规格
美团云 Redis ：未提供性能规格文档

2. 性能指标

通过我们看各大厂商提供的指标，我们不难发现，主要是 QPS 。

3. 测试工具

Redis 的性能测试工具，目前主流使用的是 redis-benchmark 。为什么这么说呢？

在我们 Google 搜索 “Redis 性能测试”时，清一色的文章选择的工具，清一色的都是 redis-benchmark 。
我翻看了云厂商（腾讯云、UCloud 等），提供的测试方法，都是基于 redis-benchmark 。

当然，也是有其它工具：

memtier_benchmark ：目前阿里云提供的测试方法，是基于它来实现，具体可以看看《阿里云 Redis —— 测试工具》。
YCSB ：YCSB 能够测试的服务特别多，上一节我们就介绍了对 MongoDB 的性能测试。

考虑到主流，本文使用 redis-benchmark 作为性能测试工具。

4. redis-benchmark

FROM 《Redis 有多快?》
Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求。（类似于 Apache ab 程序）。

4.1 测试环境

型号：ecs.c5.xlarge

艿艿：和我一样抠门（穷）的胖友，可以买竞价类型服务器，使用完后，做成镜像。等下次需要使用的时候，恢复一下。HOHO 。

系统：CentOS 7.6 64位
CPU ：4 核
内存：8 GB
磁盘：40 GB ESSD 云盘
Redis ：5.0.5

不想编译安装的朋友，可以看看《How to Install Latest Redis on CentOS 7》文章。

4.2 安装工具

因为 redis-benchmark 是 Redis 自带的，所以不需要专门去安装，舒服~。

4.3 使用指南

redis-benchmark 的使用非常简单，只要了解它每个参数的作用，就可以非常方便的执行一次性能测试。我们来一起看看有哪些参数。执行 redis-benchmark -h 命令，返回参数列表：

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests>] [-k <boolean>] -h <hostname>      Server hostname (default 127.0.0.1) -p <port>          Server port (default 6379) -s <socket>        Server socket (overrides host and port) -a <password>      Password for Redis Auth -c <clients>       Number of parallel connections (default 50) -n <requests>      Total number of requests (default 100000) -d <size>          Data size of SET/GET value in bytes (default 3) --dbnum <db>       SELECT the specified db number (default 0) -k <boolean>       1=keep alive 0=reconnect (default 1) -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD  Using this option the benchmark will expand the string __rand_int__  inside an argument with a 12 digits number in the specified range  from 0 to keyspacelen-1. The substitution changes every time a command  is executed. Default tests use this to hit random keys in the  specified range. -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline). -e                 If server replies with errors, show them on stdout.                    (no more than 1 error per second is displayed) -q                 Quiet. Just show query/sec values --csv              Output in CSV format -l                 Loop. Run the tests forever -t <tests>         Only run the comma separated list of tests. The test                    names are the same as the ones produced as output. -I                 Idle mode. Just open N idle connections and wait.

? 实际 redis-benchmark -h 命令并不是类似很多命令 --help 返回参数列表，仅仅是因为 redis-benchmark -h 命令是一条错误的命令，所以返回参数列表，提示我们应该怎么做。
连接 Redis 服务相关
-h ：Redis 服务主机地址，默认为 127.0.0.1 。

-p ：Redis 服务端口，默认为 6379 。
-s ：指定连接的 Redis 服务地址，用于覆盖 -h 和 -p 参数。一般情况下，我们并不会使用。
-a ：Redis 认证密码。
--dbnum ：选择 Redis 数据库编号。
k ：是否保持连接。默认会持续保持连接。

请求相关参数

默认情况下，使用 rand_int 作为 KEY 。
通过设置 -r 参数，可以设置 KEY 的随机范围。例如说，-r 10 生成的 KEY 范围是 [0, 9) 。
? 重要：一般情况下，我们会自动如下参数，以达到不同场景下的性能测试。
-c ：并发的客户端数（每个客户端，等于一个并发）。
-n ：总共发起的操作（请求）数。例如说，一次 GET 命令，算作一次操作。
-d ：指定 SET/GET 操作的数据大小，单位：字节。
-r ：SET/GET/INCR 使用随机 KEY ，SADD 使用随机值。
-P ：默认情况下，Redis 客户端一次请求只发起一个命令。通过 -P 参数，可以设置使用 pipelining功能，一次发起指定个请求，从而提升 QPS 。
-l ：循环，一直执行基准测试。
-t ：指定需要测试的 Redis 命令，多个命令通过逗号分隔。默认情况下，测试 PING_INLINE/PING_BULK/SET/GET 等等命令。如果胖友只想测试 SET/GET 命令，则可以 -t SET,GET 来指定。
-I ：Idle 模式。仅仅打开 N 个 Redis Idle 个连接，然后等待，啥也不做。不是很理解这个参数的目的，目前猜测，仅仅用于占用 Redis 连接。

输出相关：

-e ：如果 Redis Server 返回错误，是否将错误打印出来。默认情况下不打印，通过该参数开启。
-q ：精简输出结果。即只展示每个命令的 QPS 测试结果。如果不理解的胖友，跑下这个参数就可以很好的明白了。
--csv ：按照 CSV 的格式，输出结果。

4.4 快速测试

redis-benchmark

在安装 Redis 的服务器上，直接执行，不带任何参数，即可进行测试。测试结果如下：

====== PING_INLINE ======  100000 requests completed in 1.18 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds84388.19 requests per second====== PING_BULK ======  100000 requests completed in 1.17 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds85106.38 requests per second====== SET ======  100000 requests completed in 1.18 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 1 milliseconds99.95% <= 2 milliseconds99.95% <= 3 milliseconds100.00% <= 3 milliseconds85034.02 requests per second====== GET ======  100000 requests completed in 1.17 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 1 milliseconds99.99% <= 2 milliseconds100.00% <= 2 milliseconds85106.38 requests per second====== INCR ======  100000 requests completed in 1.19 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 2 milliseconds99.96% <= 3 milliseconds100.00% <= 3 milliseconds84317.03 requests per second====== LPUSH ======  100000 requests completed in 1.17 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds85763.29 requests per second====== RPUSH ======  100000 requests completed in 1.15 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds87260.03 requests per second====== LPOP ======  100000 requests completed in 1.17 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds85689.80 requests per second====== RPOP ======  100000 requests completed in 1.16 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds86281.27 requests per second====== SADD ======  100000 requests completed in 1.17 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 2 milliseconds99.96% <= 3 milliseconds100.00% <= 3 milliseconds85106.38 requests per second====== HSET ======  100000 requests completed in 1.14 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds87719.30 requests per second====== SPOP ======  100000 requests completed in 1.16 seconds  50 parallel clients  3 bytes payload  keep alive: 1100.00% <= 0 milliseconds85836.91 requests per second====== LPUSH (needed to benchmark LRANGE) ======  100000 requests completed in 1.15 seconds  50 parallel clients  3 bytes payload  keep alive: 199.92% <= 1 milliseconds100.00% <= 1 milliseconds86805.56 requests per second====== LRANGE_100 (first 100 elements) ======  100000 requests completed in 2.03 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 1 milliseconds99.95% <= 2 milliseconds99.96% <= 3 milliseconds99.99% <= 4 milliseconds100.00% <= 4 milliseconds49261.09 requests per second====== LRANGE_300 (first 300 elements) ======  100000 requests completed in 4.58 seconds  50 parallel clients  3 bytes payload  keep alive: 16.06% <= 1 milliseconds99.78% <= 2 milliseconds99.94% <= 3 milliseconds99.98% <= 4 milliseconds100.00% <= 5 milliseconds100.00% <= 5 milliseconds21815.01 requests per second====== LRANGE_500 (first 450 elements) ======  100000 requests completed in 6.51 seconds  50 parallel clients  3 bytes payload  keep alive: 10.04% <= 1 milliseconds83.91% <= 2 milliseconds99.93% <= 3 milliseconds99.97% <= 4 milliseconds99.98% <= 5 milliseconds99.99% <= 6 milliseconds100.00% <= 7 milliseconds100.00% <= 7 milliseconds15372.79 requests per second====== LRANGE_600 (first 600 elements) ======  100000 requests completed in 8.66 seconds  50 parallel clients  3 bytes payload  keep alive: 10.03% <= 1 milliseconds62.47% <= 2 milliseconds98.11% <= 3 milliseconds99.86% <= 4 milliseconds99.94% <= 5 milliseconds99.97% <= 6 milliseconds99.98% <= 7 milliseconds100.00% <= 8 milliseconds100.00% <= 8 milliseconds11551.35 requests per second====== MSET (10 keys) ======  100000 requests completed in 1.11 seconds  50 parallel clients  3 bytes payload  keep alive: 199.95% <= 2 milliseconds99.96% <= 3 milliseconds100.00% <= 3 milliseconds90009.01 requests per second

基本可以看到，常用的 GET/SET/INCR 等命令，都在 8W+ QPS 以上，美滋滋。

4.5 精简测试

redis-benchmark -t set,get,incr -n 1000000 -q

通过 -t 参数，设置仅仅测试 SET/GET/INCR 命令
通过 -n 参数，设置每个测试执行 1000000 次操作。
通过 -q 参数，设置精简输出结果。

执行结果如下：

[root@iZuf6hci646px19gg3hpuwZ ~]# redis-benchmark -t set,get,incr -n 1000000 -qSET: 85888.52 requests per secondGET: 85881.14 requests per secondINCR: 86722.75 requests per second

是不是一下子精简很多？！

4.6 pipeline 测试

在一些业务场景，我们希望通过 Redis pipeline 功能，批量提交命令给 Redis Server ，从而提升性能。那么，我们就来测试下

redis-benchmark -t set,get,incr -n 1000000 -q -P 10

通过 -P 参数，设置每个 pipeline 执行 10 次 Redis 命令。

执行结果如下：

SET: 625782.19 requests per secondGET: 827814.62 requests per secondINCR: 745712.19 requests per second

相比「4.5 精简测试」来说，性能有了 8-10 倍左右的提升，无敌！

4.7 随机 KEY 测试

本小节，我们主要来看看 -r 参数的使用。为了更好的对比，我们来先看看未使用的 -r 的情况，然后再测试使用 -r 的情况。

未使用

redis-benchmark -t set -n 1000 -q

我们来查看 Redis 中，有哪些 KEY ：

$ redis-cli flushdb # 用于清空 Redis 中的数据$ redis-cli keys \*1) "key:__rand_int__"

只有一个以 key: 开头，结尾是 rand_int" 的 KEY 。这说明，整个测试过程，使用的都是这个 KEY 。

使用

$ redis-cli flushdb # 用于清空 Redis 中的数据$ redis-benchmark -t set -n 1000 -q -r 10

通过 -r 10 参数，设置 KEY 的随机范围为 -r 10 。

我们来查看 Redis 中，有哪些 KEY ：

$ redis-cli keys \* 1) "key:000000000001" 2) "key:000000000009" 3) "key:000000000004" 4) "key:000000000005" 5) "key:000000000002" 6) "key:000000000008" 7) "key:000000000003" 8) "key:000000000007" 9) "key:000000000006"10) "key:000000000000"