redis性能压测

一。	压测信息统计
	基础信息		阿里云监控信息
	所属环境	用户数 （单位：个）	Keys （单位：个）	ConnCount （单位：个）	TotalQps （单位：次）	CpuUsage （单位：％）
	线上环境	7741	289611.12	2543.33	4104.4	1.2
	压测环境	百万	37412623.69	328553.1585	530215.7344	70％<
	按键：后端的Redis的所有数据库的密钥个数的总和，对集合实例会汇聚后端所有节点的数据 ConnCount：当前的Redis的的客户端连接个数        TotalQps：当前的Redis的的每秒操作次数        CpuUsage：当前的Redis的后端的的CPU使用率
二。	redis的的的基准测试（通过redis的的的基准测试实现）
2.1	Redis的的的基准测试场景设置：
	通过不断增加客户端和请求数，获取每秒钟的指令执行数（./redis-benchmark -h 172.16.6.250 -p 6379 -c 2000 -n 40000 -q）
	./redis-benchmark -h 172.16.6.250 -p 6379 -c -n -q			运行在安静的模式中，且只使用单一的关键
	./redis-benchmark -h 172.16.6.250 -p 6379 -n 100000 -q			运行在安静的模式中，且只使用单一的关键
	./redis-benchmark -h 172.16.6.250 -p 6379 -n 100000 -q script load“redis.call（'set'，'foo'，'bar'）”			使用直接命令来运行
	./redis-benchmark -h 172.16.6.250 -p 6379 -r 100000 -n 100000 -q			运行在安静的模式中，并且设置10万随机密钥
	./redis-benchmark -h 172.16.6.250 -p 6379 -c 100 -r 100000 -n 100000 -q			模拟100个客户端
	./redis-benchmark -h 172.16.6.250 -p 6379 -c 10 -r 100000 -n 100000 -q			模拟10个客户端
	./redis-benchmark -h 172.16.6.250 -p 6379 -r 100000 -n 100000 -P 16 -q			流水线16条命令的测试
2.2	Redis的的的基准测试结果统计：
	场景内容		集请求（单位：次/秒）		获得请求（单位：次/秒）
	单一键，50客户端		145560.41		142653.36
	随机密钥，50客户端		132978.72		146842.88
	随机密钥，100客户端		124688.28		136054.05
	随机密钥，10客户端		137931.03		136425.46
	随机密钥，50客户端，并发执行		396825.41		403325.53
	从上面表格可以看出：  （1）对于相同客户端的情况下，随机密钥的每秒请求数，SET减少，GET增加;  （2）在随机生成密钥值的情况下，SET，SADD操作随着客户端数增加，每秒请求数减少;考虑到高速缓存命中的情况，其他命令变化趋势没有规律;  （3）其他条件一致，并发执行情况下，命令各种都是有大幅度增加  从上面可以得出结论：在真实环境下，应对大数据，大并发，可以通过增加缓存大小，并发执行来提高吞吐量。
三。	Redis的的的性能测试统计
3.1	不同压测数据下每秒执行次数：
	通过对基准数据/线上数据/压测数据图表分析得出，客户端/请求书/键的增加，并未对redis的的的每秒处理指令数产生较大的变化;
	但是实际压测的连接未达到预期查询查询查询查询结果的328553.16，因为达到10000以上的连接数时，只能执行PING_INLINE指令，在连接最大值为7000左右时才能正常完成所有指令;
3.2	Redis的的的所在服务器硬件资源监测：
	通过阿里云redis的已有硬件资源监控系统得到如下的数据，连接在使用压测数据进行压测时峰值达到了6046，TotalQps峰值达到了45207.5，分别与我们期望的结果328553.1585 / 530215.7344都有较大的差距，产生的原因是客户端连接数达到上限，未能实现预期的链接.CPU的使用率趋于稳定，没有明显飙升的情况，所以CPU不太可能成为redis的的的的性能瓶颈。