redis 自带了一个叫redis-benchmark的工具来模拟 n 个客户端同时发出 m 个请求。 （类似于 apacheab程序）。使用命令 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)     -c <clients>       number of parallel connections (default 50)     -n <requests>      total number of requests (default 10000)     -d <size>          data size of set/get value in bytes (default 2)     -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 get/set keys      in the form mykey_rand:000000012456 instead of constant      keys, the <keyspacelen> argument determines the max      number of values for the random number. for instance      if set to 10 only rand:000000000000 - rand:000000000009      range will be allowed.     -p <numreq>        pipeline <numreq> requests. default 1 (no pipeline).     -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 实例。一般这样启动测试：
redis-benchmark -q -n 100000
这个工具使用起来非常方便，同时你可以使用自己的基准测试工具， 不过开始基准测试时候，我们需要注意一些细节。
只运行一些测试用例的子集每次运行redis-benchmark时不必默认运行所有测试。你可以使用参数 -t 来指定需要运行的测试用例，例如以下示例：
$ redis-benchmark -t set,lpush -n 100000 -qset: 74239.05 requests per secondlpush: 79239.30 requests per second
在上面的测试中，我们只运行了 set 和 lpush 命令， 并且运行在安静模式中（使用-q参数）。
也可以直接指定命令来直接运行，比如下面的范例：
$ redis-benchmark -n 100000 -q script load redis.call('set','foo','bar')script load redis.call('set','foo','bar'): 69881.20 requests per second
选择测试键的范围大小默认情况下面，基准测试使用单一的 key。在一个基于内存的数据库里， 单一 key 测试和真实情况下面不会有巨大变化。当然，扩大密钥范围可以模拟真实情况下的缓存未命中。
这时候我们可以使用-r命令。例如，如果我们希望连续进行 100 万次 set 操作，每次使用 10 万个随机 key，可以使用以下命令：
$ redis-cli flushallok$ redis-benchmark -t set -r 100000 -n 1000000====== set ======  1000000 requests completed in 13.86 seconds  50 parallel clients  3 bytes payload  keep alive: 199.76% `<=` 1 milliseconds99.98% `<=` 2 milliseconds100.00% `<=` 3 milliseconds100.00% `<=` 3 milliseconds72144.87 requests per second$ redis-cli dbsize(integer) 99993
使用 pipelining默认情况下，每个客户端都是在一个请求完成之后才发送下一个请求 （benchmark 会模拟 50 个客户端除非使用-c指定特别的数量）， 这意味着服务器几乎是按顺序读取每个客户端的命令。also rtt is payed as well.
真实世界会更复杂，redis 支持/topics/pipelining，使得可以一次性执行多条命令成为可能。使用redis pipelining可以增加服务器的每秒事务处理率。
下面这个案例是在 macbook air 11" 上使用 pipelining 组织 16 条命令的测试范例：
$ redis-benchmark -n 1000000 -t set,get -p 16 -qset: 403063.28 requests per secondget: 508388.41 requests per second
记得在多条命令需要处理时候使用 pipelining。
陷阱和错误的认识第一点是显而易见的：基准测试的黄金准则是使用相同的标准。进行 redis 不同版本的测试时，可以采取同等任务量测试或使用相同参数进行测试。 如果把 redis 和其他工具测试，那就需要小心功能细节差异。
redis 是一个服务器：所有的命令都包含网络或 ipc 消耗。这意味着和它和 sqlite， berkeley db， tokyo/kyoto cabinet 等比较起来无意义， 因为大部分的消耗都在网络协议上面。
redis 的大部分常用命令都有确认返回。例如，mongodb的写操作不会返回确认，而有些数据存储系统则会。把 redis 和其他单向调用命令存储系统比较意义不大。
简单的循环操作 redis 其实不是对 redis 进行基准测试，而是测试你的网络（或者 ipc）延迟。想要真正测试 redis，需要使用多个连接（比如 redis-benchmark)， 或者使用 pipelining 来聚合多个命令，另外还可以采用多线程或多进程。
redis 是一个内存数据库，同时提供一些可选的持久化功能。 如果你想和一个持久化服务器（mysql, postgresql 等等） 对比的话， 那你需要考虑启用 aof 和适当的 fsync 策略。
redis 是单线程服务。它并没有设计为多 cpu 进行优化。如果想要从多核获取好处， 那就考虑启用多个实例吧。将单实例 redis 和多线程数据库对比是不公平的。
一个普遍的误解是 redis-benchmark 特意让基准测试看起来更好， 所表现出来的数据像是人造的，而不是真实产品下面的。
redis-benchmark 工具能够迅速简便地计算出在特定硬件条件下机器的性能参数。 但是，通常情况下面这并不是 redis 服务器可以达到的最大吞吐量。使用 pipelining 和更快的客户端（如 hiredis），能够实现更高的吞吐量。 redis-benchmark 默认情况下面仅仅使用并发来提高吞吐量（创建多条连接）。它没有采用pipelining或其他并发技术，只是使用了多个连接而非多线程。
如果想使用 pipelining 模式来进行基准测试（了达到更高吞吐量），可以使用-p参数。很多在生产环境中使用 redis 的应用采用了这种方案以提高性能。
最后，基准测试需要使用相同的操作和数据来对比，如果这些不一样， 那么基准测试是无意义的。
例如，redis和memcached可以在单线程模式下进行get/set操作的比较。 两者都是内存数据库，协议也基本相同，甚至把多个请求合并为一条请求的方式也类似 （pipelining）。在使用相同数量的连接后，这个对比是很有意义的。
下面这个很不错例子是在 redis（antirez）和 memcached（dormando）测试的。
antirez 1 - on redis, memcached, speed, benchmarks and the toilet
dormando - redis vs memcached (slightly better bench)
antirez 2 - an update on the memcached/redis benchmark
你可以发现相同条件下面最终结果是两者差别不大。请注意最终测试时候， 两者都经过了充分优化。
最后，当特别高性能的服务器在基准测试时候（比如 redis、memcached 这类）， 很难让服务器性能充分发挥，通常情况下，客户端回事瓶颈限制而不是服务器端。 在这种情况下面，客户端（比如 benchmark 程序自身）需要优化，或者使用多实例， 从而能达到最大的吞吐量。
影响 redis 性能的因素有几个因素直接决定 redis 的性能。它们能够改变基准测试的结果， 所以我们必须注意到它们。通常情况下， redis 的默认参数已经足够提供高效的性能，因此不需要进行调优。
网络带宽和延迟通常是最大短板。我建议在进行基准测试之前先使用 ping 命令对服务端和客户端之间的延迟进行检测。根据带宽，可以计算出最大吞吐量。 比如将 4 kb 的字符串塞入 redis，吞吐量是 100000 q/s，那么实际需要 3.2 gbits/s 的带宽，所以需要 10 gbits/s 网络连接， 1 gbits/s 是不够的。在许多在线服务中，网络带宽往往比 cpu 更早地成为限制redis吞吐量的因素。 为了达到高吞吐量突破 tcp/ip 限制，最后采用 10 gbits/s 的网卡， 或者多个 1 gbits/s 网卡。
cpu 是另外一个重要的影响因素，由于是单线程模型，redis 更喜欢大缓存快速 cpu， 而不是多核。这种场景下面，比较推荐 intel cpu。amd cpu 可能只有 intel cpu 的一半性能（通过对 nehalem ep/westmere ep/sandy 平台的对比）。如果其他条件相同，那么cpu就是redis-benchmark的瓶颈。
在小对象存取时候，内存速度和带宽看上去不是很重要，但是对大对象（> 10 kb）， 它就变得重要起来。一般来说，人们不会为了优化 redis 购买更高性能的内存模块。redis 在 vm 上会变慢。虚拟化对普通操作会有额外的消耗，redis 对系统调用和网络终端不会有太多的 overhead。特别关注延迟的情况下，建议将 redis 部署在物理服务器上运行。在最先进的虚拟化设备（vmware）上面，redis-benchmark 的测试结果比物理机器上慢了一倍，很多 cpu 时间被消费在系统调用和中断上面。
如果服务器和客户端都运行在同一个机器上面，那么 tcp/ip loopback 和 unix domain sockets 都可以使用。对 linux 来说，使用 unix socket 可以比 tcp/ip loopback 快 50%。redis-benchmark 默认使用 tcp/ip 回环接口。
当使用大量 pipelining 时，unix 域套接字的好处就变得不那么显著了。
当使用网络连接时，并且以太网网数据包在 1500 bytes 以下时， 将多条命令包装成 pipelining 可以大大提高效率。事实上，处理 10 bytes，100 bytes， 1000 bytes 的请求时候，吞吐量是差不多的，详细可以见下图。
redis 的性能在多核 cpu 服务器上还取决于 numa 配置和处理器绑定位置。redis-benchmark的最显著的影响是它会随机地利用cpu核心。为了获得精准的结果， 需要使用固定处理器工具（在 linux 上可以使用 taskset 或 numactl）。 最有效的办法是将客户端和服务端分离到两个不同的 cpu 来高校使用三级缓存。 这里有一些使用 4 kb 数据 set 的基准测试，针对三种 cpu（amd istanbul, intel nehalem ex， 和 intel westmere）使用不同的配置。请注意， 这不是针对 cpu 的测试。
在高配置下面，客户端的连接数也是一个重要的因素。redis 的事件循环得益于 epoll/kqueue，因此具有很高的可扩展性。redis 已经在超过 60000 连接下面基准测试过， 仍然可以维持 50000 q/s。一条经验法则是，30000 的连接数只有 100 连接的一半吞吐量。 下面有一个关于连接数和吞吐量的测试。
在高配置下面，可以通过调优 nic 来获得更高性能。最高性能在绑定 rx/tx 队列和 cpu 内核下面才能达到，还需要开启 rps（网卡中断负载均衡）。更多信息可以在thread。jumbo frames 还可以在大对象使用时候获得更高性能。
在不同平台下面，redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。若非编译自行进行的 redis，可用 info 命令验证内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的 redis 实例来查看。
其他需要注意的点任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。
一个好的实践是尽可能在隔离的硬件上面测试。需要检查基准测试是否受到其他服务器活动的影响，如果无法实现的话。
有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 cpu 分配策略。 这种策略可以在 os 层面配置。有些 cpu 型号相对其他能更好的调整 cpu 负载。 为了达到可重现的测试结果，最好在做基准测试时候设定 cpu 到最高使用限制。
一个重要因素是配置尽可能大内存，千万不要使用 swap。注意 32 位和 64 位 redis 有不同的内存限制。
注意在执行基准测试时，如果使用了 rdb 或 aof，请避免同时进行其他 i/o 操作。 避免将 rdb 或 aof 文件放到 nas 或 nfs 共享或其他依赖网络的存储设备上面（比如 amazon ec2 上 的 ebs）。
将 redis 日志级别设置到 warning 或者 notice。避免将日志放到远程文件系统。
避免使用检测工具，它们会影响基准测试结果。查看服务器状态可使用 info 命令，但使用 monitor 命令会严重影响测试准确性。
不同云主机和物理机器上的基准测试结果这些测试模拟了 50 客户端和 200w 请求。
使用了 redis 2.6.14。
使用了 loopback 网卡。
key 的范围是 100 w。
同时测试了 有 pipelining 和没有的情况（16 条命令使用 pipelining）。
intel(r) xeon(r) cpu e5520 @ 2.27ghz (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -p 16 -qset: 552028.75 requests per secondget: 707463.75 requests per secondlpush: 767459.75 requests per secondlpop: 770119.38 requests per second
intel(r) xeon(r) cpu e5520 @ 2.27ghz (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -qset: 122556.53 requests per secondget: 123601.76 requests per secondlpush: 136752.14 requests per secondlpop: 132424.03 requests per second
linode 2048 instance (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -p 16set: 195503.42 requests per secondget: 250187.64 requests per secondlpush: 230547.55 requests per secondlpop: 250815.16 requests per second
linode 2048 instance (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -qset: 35001.75 requests per secondget: 37481.26 requests per secondlpush: 36968.58 requests per secondlpop: 35186.49 requests per second
更多使用 pipeline 的测试$ redis-benchmark -n 100000====== set ======  100007 requests completed in 0.88 seconds  50 parallel clients  3 bytes payload  keep alive: 158.50% <= 0 milliseconds99.17% <= 1 milliseconds99.58% <= 2 milliseconds99.85% <= 3 milliseconds99.90% <= 6 milliseconds100.00% <= 9 milliseconds114293.71 requests per second====== get ======  100000 requests completed in 1.23 seconds  50 parallel clients  3 bytes payload  keep alive: 143.12% <= 0 milliseconds96.82% <= 1 milliseconds98.62% <= 2 milliseconds100.00% <= 3 milliseconds81234.77 requests per second====== incr ======  100018 requests completed in 1.46 seconds  50 parallel clients  3 bytes payload  keep alive: 132.32% <= 0 milliseconds96.67% <= 1 milliseconds99.14% <= 2 milliseconds99.83% <= 3 milliseconds99.88% <= 4 milliseconds99.89% <= 5 milliseconds99.96% <= 9 milliseconds100.00% <= 18 milliseconds68458.59 requests per second====== lpush ======  100004 requests completed in 1.14 seconds  50 parallel clients  3 bytes payload  keep alive: 162.27% <= 0 milliseconds99.74% <= 1 milliseconds99.85% <= 2 milliseconds99.86% <= 3 milliseconds99.89% <= 5 milliseconds99.93% <= 7 milliseconds99.96% <= 9 milliseconds100.00% <= 22 milliseconds100.00% <= 208 milliseconds88109.25 requests per second====== lpop ======  100001 requests completed in 1.39 seconds  50 parallel clients  3 bytes payload  keep alive: 154.83% <= 0 milliseconds97.34% <= 1 milliseconds99.95% <= 2 milliseconds99.96% <= 3 milliseconds99.96% <= 4 milliseconds100.00% <= 9 milliseconds100.00% <= 208 milliseconds71994.96 requests per second
注意：包大小从 256 到 1024 或者 4096 bytes 不会改变结果的量级 （但是到 1024 bytes 后，gets 操作会变慢）。同样的，50 到 256 客户端的测试结果相同。当使用10个客户端时，总吞吐量无法达到最大吞吐量。
不同机器可以获的不一样的结果，下面是intel t5500 1.66 ghz 在 linux 2.6下面的结果：
$ ./redis-benchmark -q -n 100000set: 53684.38 requests per secondget: 45497.73 requests per secondincr: 39370.47 requests per secondlpush: 34803.41 requests per secondlpop: 37367.20 requests per second
另外一个是 64 位 xeon l5420 2.5 ghz 的结果：
$ ./redis-benchmark -q -n 100000ping: 111731.84 requests per secondset: 108114.59 requests per secondget: 98717.67 requests per secondincr: 95241.91 requests per secondlpush: 104712.05 requests per secondlpop: 93722.59 requests per second
高性能硬件下面的基准测试redis2.4.2 。
默认连接数，数据包大小 256 bytes。
linux 是sles10 sp3 2.6.16.60-0.54.5-smp，cpu 是 2 xintel x5670 @ 2.93 ghz。
固定 cpu，但是使用不同 cpu 内核。
使用 unix domain socket：
$ numactl -c 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256ping (inline): 200803.22 requests per secondping: 200803.22 requests per secondmset (10 keys): 78064.01 requests per secondset: 198412.69 requests per secondget: 198019.80 requests per secondincr: 200400.80 requests per secondlpush: 200000.00 requests per secondlpop: 198019.80 requests per secondsadd: 203665.98 requests per secondspop: 200803.22 requests per secondlpush (again, in order to bench lrange): 200000.00 requests per secondlrange (first 100 elements): 42123.00 requests per secondlrange (first 300 elements): 15015.02 requests per secondlrange (first 450 elements): 10159.50 requests per secondlrange (first 600 elements): 7548.31 requests per second
使用 tcp loopback：
$ numactl -c 6 ./redis-benchmark -q -n 100000 -d 256ping (inline): 145137.88 requests per secondping: 144717.80 requests per secondmset (10 keys): 65487.89 requests per secondset: 142653.36 requests per secondget: 142450.14 requests per secondincr: 143061.52 requests per secondlpush: 144092.22 requests per secondlpop: 142247.52 requests per secondsadd: 144717.80 requests per secondspop: 143678.17 requests per secondlpush (again, in order to bench lrange): 143061.52 requests per secondlrange (first 100 elements): 29577.05 requests per secondlrange (first 300 elements): 10431.88 requests per secondlrange (first 450 elements): 7010.66 requests per secondlrange (first 600 elements): 5296.61 requests per second
以上就是redis基准参数怎么查看的详细内容。