你是怎么了解redis性能测试、慢查询、redis的可视化管理工具

最新推荐文章于 2024-08-21 09:03:37 发布

凉梨汁儿

最新推荐文章于 2024-08-21 09:03:37 发布

阅读量469

点赞数

文章标签： redis 数据库

本文链接：https://blog.csdn.net/weixin_45568391/article/details/108523806

版权

1.Redis 性能测试

为什么需要性能测试
性能测试的使用场景
1.技术选型，比如测试Memcached和Redis
2. 对比单机Redis和集群Redis的吞吐量
3. 评估不同类型的储存性能，例如集合有序集合
4. 对比开启持久化和关闭持久化的吞吐量
5. 对比调优和为调优的吞吐量
6. 对比不同Redis版本的吞吐量，作为是否升级的一个参考标准

诸如此类的情况，我们都需要进行性能测试。

性能测试的几种方式
既然性能测试使用场景那么多，那要怎么进行性能测试呢？
目前比较主流的性能测试分为两种：

编写代码模拟并发进行性能测试；
使用 redis-benchmark 进行测试。

因为自己编写代码进行性能测试的方式不够灵活，且很难短时间内模拟大量的并发数，所以并不建议使用这种方式。幸运的是 Redis 本身给我们提供了性能测试工具 redis-benchmark（Redis 基准测试）

基准测试实战
redis-benchmark 位于 Redis 的 src 目录下，我们可以使用 ./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 ：服务器的主机名（默认值为 127.0.0.1）。
• -p ：服务器的端口号（默认值为 6379）。
• -s ：服务器的套接字（会覆盖主机名和端口号）。
• -a ：登录 Redis 时进行身份验证的密码。
• -c ：并发的连接数量（默认值为 50）。
• -n ：发出的请求总数（默认值为 100000）。
• -d ：SET/GET 命令所操作的值的数据大小，以字节为单位（默认值为 2）。
• –dbnum ：选择用于性能测试的数据库的编号（默认值为 0）。
• -k ：1 = 保持连接；0 = 重新连接（默认值为 1）。
• -r ：SET/GET/INCR 命令使用随机键，SADD 命令使用随机值。通过这个选项，基准测试会将参数中的 rand_int 字符串替换为一个 12 位的整数，这个整数的取值范围从 0 到 keyspacelen-1。每次执行一条命令的时候，用于替换的整数值都会改变。通过这个参数，默认的测试方案会在指定范围之内尝试命中随机键。
• -P ：使用管道机制处理条 Redis 请求。默认值为 1（不使用管道机制）。
• -q：静默测试，只显示 QPS 的值。
• –csv：将测试结果输出为 CSV 格式的文件。
• -l：循环测试。基准测试会永远运行下去。
• -t ：基准测试只会运行列表中用逗号分隔的命令。测试命令的名称和结果输出产生的名称相同。
• -I：空闲模式，只会打开 N 个空闲的连接，然后等待。
可以看出 redis-benchmark 带的功能还是比较全的。

基本使用
在安装 Redis 服务端的机器上，我们可以不带任何参数直接执行 ./redis-benchmark 执行结果如下：

[@iZ2ze0nc5n41zomzyqtksmZ:src]$ ./redis-benchmark
====== PING_INLINE ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.81% <= 1 milliseconds
100.00% <= 2 milliseconds
79302.14 requests per second
====== PING_BULK ======
  100000 requests completed in 1.29 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.83% <= 1 milliseconds
100.00% <= 1 milliseconds
77459.34 requests per second
====== SET ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.80% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 2 milliseconds
79239.30 requests per second
====== GET ======
  100000 requests completed in 1.19 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.72% <= 1 milliseconds
99.95% <= 15 milliseconds
100.00% <= 16 milliseconds
100.00% <= 16 milliseconds
84104.29 requests per second
====== INCR ======
  100000 requests completed in 1.17 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
85397.09 requests per second
====== LPUSH ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.79% <= 1 milliseconds
100.00% <= 1 milliseconds
82169.27 requests per second
====== RPUSH ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.71% <= 1 milliseconds
100.00% <= 1 milliseconds
81900.09 requests per second
====== LPOP ======
  100000 requests completed in 1.29 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.78% <= 1 milliseconds
99.95% <= 13 milliseconds
99.97% <= 14 milliseconds
100.00% <= 14 milliseconds
77399.38 requests per second
====== RPOP ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.82% <= 1 milliseconds
100.00% <= 1 milliseconds
80192.46 requests per second
====== SADD ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.74% <= 1 milliseconds
100.00% <= 1 milliseconds
80192.46 requests per second
====== HSET ======
  100000 requests completed in 1.21 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.86% <= 1 milliseconds
100.00% <= 1 milliseconds
82440.23 requests per second
====== SPOP ======
  100000 requests completed in 1.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.92% <= 1 milliseconds
100.00% <= 1 milliseconds
81699.35 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 1.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.69% <= 1 milliseconds
99.95% <= 13 milliseconds
99.99% <= 14 milliseconds
100.00% <= 14 milliseconds
79176.56 requests per second
====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.57% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
80128.20 requests per second
====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 1.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.91% <= 1 milliseconds
100.00% <= 1 milliseconds
80064.05 requests per second
====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.78% <= 1 milliseconds
100.00% <= 1 milliseconds
76863.95 requests per second
====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 1.20 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.85% <= 1 milliseconds
100.00% <= 1 milliseconds
83263.95 requests per second
====== MSET (10 keys) ======
  100000 requests completed in 1.27 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
99.65% <= 1 milliseconds
100.00% <= 1 milliseconds
78740.16 requests per second
复制

可以看出以上都是对常用的方法 Set、Get、Incr 等进行测试，基本能达到每秒 8W 的处理级别。

精简测试
我们可以使用./redis-benchmark -t set,get,incr -n 1000000 -q命令，来对 Redis 服务器进行精简测试，测试结果如下：

[@iZ2ze0nc5n41zomzyqtksmZ:src]$ ./redis-benchmark -t set,get,incr -n 1000000 -q
SET: 81726.05 requests per second
GET: 81466.40 requests per second
INCR: 82481.03 requests per second

可以看出以上测试展示的结果非常的精简，这是因为我们设置了 -q 参数，此选项的意思是设置输出结果为精简模式，其中 -t 表示指定测试指令，-n 设置每个指令测试 100w 次。

管道测试
本课程的前面章节介绍了 Pipeline（管道）的知识，它是用于客户端把命令批量发给服务器端执行的，以此来提高程序的整体执行效率，那接下来我们测试一下 Pipeline 的吞吐量能到达多少，执行命令如下：

[@iZ2ze0nc5n41zomzyqtksmZ:src]$ ./redis-benchmark -t set,get,incr -n 1000000 -q -P 10
SET: 628535.50 requests per second
GET: 654450.25 requests per second
INCR: 647249.19 requests per second

我们发现 Pipeline 的测试很快就执行完了，同样是每个指令执行 100w 次，可以看出 Pipeline 的性能几乎是普通命令的 8 倍， -P 10 表示每次执行 10 个 Redis 命令。

基准测试的影响元素

为什么每次执行 10 个 Redis 命令，Pipeline 的效率为什么达不到普通命令的 10 倍呢？
这是因为基准测试会受到很大外部因素的影响，例如以下几个：
• 网络带宽和网络延迟可能是 Redis 操作最大的性能瓶颈，比如有 10w q/s，平均每个请求负责传输 8 KB 的字符，那我们需要的理论带宽是 7.6 Gbits/s，如果服务器配置的是 1 Gbits/s，那么一定会有很多信息在排队等候传输，因此运行效率可想而知，这也是很多 Redis 生产坏境之所以效率不高的原因；
• CPU 可能是 Redis 运行的另一个重要的影响因素，如果 CPU 的计算能力跟不上 Redis 要求的话，也会影响 Redis 的运行效率；
• 如果 Redis 运行在虚拟设备上，性能也会受影响，因为普通操作在虚拟设备上会有额外的消耗；
• 普通操作和批量操作（Pipeline）对 Redis 的吞吐量也有很大的影响。

2.Redis慢查询

Redis 慢查询作用和 MySQL 慢查询作用类似，都是为我们查询出不合理的执行命令，然后让开发人员和运维人员一起来规避这些耗时的命令，从而让服务器更加高效和健康的运行。对于单线程的 Redis 来说，不合理的使用更是致命的，因此掌握 Redis 慢查询技能对我们来说非常的关键。

如何进行慢查询？

在开始之前，我们先要了解一下 Redis 中和慢查询相关的配置项，Redis 慢查询重要的配置项有以下两个：

• slowlog-log-slower-than：用于设置慢查询的评定时间，也就是说超过此配置项的命令，将会被当成慢操作记录在慢查询日志中，它执行单位是微秒（1 秒等于 1000000 微秒）；
• slowlog-max-len：用来配置慢查询日志的最大记录数。
我们先来看它们的默认配置值：

127.0.0.1:6379> config get slowlog-log-slower-than #慢查询判断时间
1) "slowlog-log-slower-than"
2) "10000"
127.0.0.1:6379> config get slowlog-max-len #慢查询最大记录条数
1) "slowlog-max-len"
2) "128"

可以看出慢查询的临界值是 10000 微秒，默认保存 128 条慢查询记录。

修改配置项
slowlog-log-slower-than 和 slowlog-max-len 可以通过 config set xxx 的模式来修改，例如 config set slowlog-max-len 200 设置慢查询最大记录数为 200 条。
慢查询演示
我们先来设置慢查询的判断时间为 0 微秒，这样所有的执行命令都会被记录
127.0.0.1:6379> config set slowlog-log-slower-than 0
OK
接下来我们执行两条插入命令
127.0.0.1:6379> set msg xiaoming
OK
127.0.0.1:6379> set lang java
OK
最后我们使用 slowlog show 来查询慢日志

127.0.0.1:6379> slowlog get #慢日志查询
1) 1) (integer) 2 #慢日志下标
   2) (integer) 1581994139 #执行时间
   3) (integer) 5 #花费时间 (单位微秒)
   4) 1) "set" #执行的具体命令
      2) "lang"
      3) "java"
   5) "127.0.0.1:47068"
   6) ""
2) 1) (integer) 1
   2) (integer) 1581994131
   3) (integer) 6
   4) 1) "set"
      2) "msg"
      3) "xiaoming"
   5) "127.0.0.1:47068"
   6) ""
3) 1) (integer) 0
   2) (integer) 1581994093
   3) (integer) 5
   4) 1) "config"
      2) "set"
      3) "slowlog-log-slower-than"
      4) "0"
   5) "127.0.0.1:47068"
   6) ""
复制
加上本身的设置命令一共有三条“慢操作”记录，按照插入的顺序倒序存入慢查询日志中。
慢查询其他相关命令
查询指定条数慢日志
语法：slowlog get n。
127.0.0.1:6379> slowlog get 2 #查询两条
1) 1) (integer) 20
   2) (integer) 1581997567
   3) (integer) 14
   4) 1) "slowlog"
      2) "get"
      3) "4"
   5) "127.0.0.1:47068"
   6) ""
2) 1) (integer) 19
   2) (integer) 1581997544
   3) (integer) 11
   4) 1) "slowlog"
      2) "get"
      3) "3"
   5) "127.0.0.1:47068"
   6) ""
127.0.0.1:6379> slowlog get 3 #查询三条
1) 1) (integer) 22
   2) (integer) 1581997649
   3) (integer) 25
   4) 1) "set"
      2) "msg"
      3) "hi"
   5) "127.0.0.1:47068"
   6) ""
2) 1) (integer) 21
   2) (integer) 1581997613
   3) (integer) 9
   4) 1) "slowlog"
      2) "get"
      3) "2"
   5) "127.0.0.1:47068"
   6) ""
3) 1) (integer) 20
   2) (integer) 1581997567
   3) (integer) 14
   4) 1) "slowlog"
      2) "get"
      3) "4"
   5) "127.0.0.1:47068"
   6) ""
复制

获取慢查询队列长度
语法：slowlog len。

127.0.0.1:6379> slowlog len
(integer) 16

清空慢查询日志

使用 slowlog reset 来清空所有的慢查询日志

127.0.0.1:6379> slowlog reset
OK

小结
慢查询相关的两个重要参数 slowlog-log-slower-than（用于设置慢查询的评定时间）和 slowlog-max-len 用来配置慢查询日志的最大记录数，然后通过修改 config set slowlog-log-slower-than 0 把所有操作都记录在慢日志进行相关测试。我们可以使用 slowlog get [n] 查询慢操作日志，使用 slowlog reset 清空慢查询日志。最后给大家一个建议，可以定期检查慢查询日志，及时发现和改进 Redis 运行中不合理的操作。

3.Redis 的可视化管理工具

因为 Redis 官方只提供了命令行版的 Redis 客户端 redis-cli，以至于我们在使用的时候会比较麻烦，通常要输入一堆命令，而且命令行版的客户端看起来也不够直观。

RedisClient

是否收费：免费
项目介绍：Java编写的Redis连接客户端，功能丰富，并且是免费的。
支持平台：Windows
项目基地：https://github.com/caoxinyu/RedisClient

在这里插入图片描述

Redis Desktop Manager

是否收费：收费。
项目介绍：一款基于 Qt5 的跨平台 Redis 桌面管理软件。
支持平台：Windows、macOS、Linux。
项目地址：https://github.com/uglide/RedisDesktopManager

在这里插入图片描述

AnotherRedisDesktopManager

是否收费：免费。
项目介绍：一款基于 Node.js 开发的 Redis 桌面管理器，它的特点就是相对来说比较稳定，在数据量比较大的时候不会崩溃。
支持平台：Windows、macOS、Linux。
项目地址：https://github.com/qishibo/AnotherRedisDesktopManager

在这里插入图片描述