一.Redis-benchmark测试

1.执行./redis-benchmark,结果如下,在自己不加参数的情况下,默认参数有-h 默认服务器主机名为127.0.0.1 , -p 默认端口号为6379 ,-c 并发连接数默认为50 ,-n 发出的请求总数默认值为100000 ,-k 1(保持连接) ,–dbnum 选择用于性能测试的数据库的编号(默认值为0)默认情况下是对redis中的所有添加查询方法进行测试,并返回结果。
在这里插入图片描述
2.在上述默认参数情况下,加入-q表示静默测试,只显示QPS的值,不显示过程信息。
在这里插入图片描述

3.-h指定端主机地址,-p指定端口号,-c指定100个连接数,-n指定发出的请求总数为1000000,-d指定set/get命令所操作的值的数据大小为4,以字节为单位。执行结果如下,每秒所能接受的请求数。
在这里插入图片描述

4.此部分展示将测试结果输出到csv文件中,即加入参数–csv >> 文件名.csv,所写入的结果为请求方法和每秒内接受的请求数。
在这里插入图片描述
csv结果展示
在这里插入图片描述
5.测试中可以用-t指定测试方法,多方法用,号隔开
在这里插入图片描述
6.-P参数的添加,参数使用管道机制处理,管道机制就是在默认不开启的情况下客户端只会在收到一个命令的响应信息后,才会发送下一个命令,而加上-P并指定数量,就是并发的读取设置数量下的操作命令。
下图为加参数的情况:
在这里插入图片描述
下图是不使用-P的情况:
在这里插入图片描述
可以发现在使用-P并指定管道数量的时候,同等数量级要求,前后每秒内所接收的请求数有了很大的提升。但是通过过程可以看到,再加了管道之后再1毫秒的时候是几乎不接受请求的,这是一个弊端。

8.-l参数,在加入之后,就是循环的测试一个或者多个方法循环执行。
在这里插入图片描述
9.在指定执行set方法时,加入-r参数表示使用随机数作为key,可指定范围,这是一个真实的插入,插入结果如图:
在这里插入图片描述

二.Memtier-benchmark测试

1.在直接执行不使用其它参数的情况下,有默认参数会执行,例如-s服务器地址默认是localhost;-p服务器端口号,默认6379;-n每个客户端发出的请求总数,默认值是10000;-c每个线程驱动的客户端数量默认值50,;-t基准测试使用的线程数量默认值是4;–ratio,SET和GET操作的比率默认值是1:10;–pipeline管道请求的并发数量默认值为1等等。
在这里插入图片描述
2.用参数显性展示和设定主机地址,端口号,指定每个客户端发出的请求总数-n,以及每个线程驱动的客户端数量-c,线程数量-t,并将运行结果写入到指定文件中—client-stats表示每个客户端的统计文件,–out-file表示输出的结果文件
在这里插入图片描述
结果展示:
在这里插入图片描述
3.—ratio=1:20指定set和get操作的比率为1:20,–pipeline表示开通16条管道
在这里插入图片描述
4.—data-size-pattern=这个参数的取值有R或者S,R代表random,S代表sequence,在给定一个范围值之后,该参数如果配置成R则会随机的在这个定义好的范围内去取值,配置成S则会顺序均匀的去取值;–key-minimum测试键ID的最小值,默认值为0,–key-maximum为最大值默认10000000
在这里插入图片描述
执行之后存入的值:
在这里插入图片描述
5.—key-prefix=PREFIX参数可以更改测试时插入值的前缀,具体展示如下
在这里插入图片描述
插入结果:
在这里插入图片描述
6.–data-size-list参数帮助我们对key值的大小进行配比,按照一定比例模拟key值,例:–data-size-list=4000:50,16000:50上面的代表4k大小的k值占比50%,16k大小的key值占比50%,也可以增加3个key或者更多,必须保证权重之和100%,记录是这样的,但是实际插入发现别没有很大变化。
在这里插入图片描述

QPS和TPS

QPS:每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

对应fetches/sec,即每秒的响应请求数,也即是最大吞吐能力。

QPS与TPS的区别?

假如一个大胃王一秒能吃10个包子,一个女孩子0.1秒能吃1个包子,那么他们是不是一样的呢?答案是否定的,因为这个女孩子不可能在一秒钟吃下10个包子,她可能要吃很久。这个时候这个大胃王就相当于TPS,而这个女孩子则是QPS。

影响吞吐量因素:

一个系统的吞吐量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。

QPS(TPS):每秒钟request/事务 数量

并发数: 系统同时处理的request/事务数

响应时间: 一般取平均响应时间

(很多人经常会把并发数和TPS理解混淆)

理解了上面三个要素的意义之后,就能推算出它们之间的关系:

QPS(TPS)= 并发数/平均响应时间

tps :每秒的响应事务数量

qps : 每秒的响应请求数量

吞吐量(throughput)(qps):并发在多少的时候,网站的qps是多少

QPS(TPS)= 并发数/平均响应时间

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐