今天搭建了redis环境，使用自带的benchmark进行了性能测试
选择测试键的范围大小
默认情况下面，基准测试使用单一的 key。在一个基于内存的数据库里， 单一 key 测试和真实情况下面不会有巨大变化。当然，使用一个大的 key 范围空间， 可以模拟现实情况下面的缓存不命中情况
这时候我们可以使用 -r 命令。比如，假设我们想设置 10 万随机 key 连续 SET 100 万次，我们可以使用下列的命令：
$ redis-cli flushall
OK
$ redis-benchmark -t set -r 100000 -n 1000000
使用 pipelining
默认情况下，每个客户端都是在一个请求完成之后才发送下一个请求 （benchmark 会模拟 50 个客户端除非使用 -c 指定特别的数量）， 这意味着服务器几乎是按顺序读取每个客户端的命令。Also RTT is payed as well.
真实世界会更复杂，Redis 支持 /topics/pipelining，使得可以一次性执行多条命令成为可能。 Redis pipelining 可以提高服务器的 TPS。 下面这个案例是在 Macbook air 11” 上使用 pipelining 组织 16 条命令的测试范例：
$ redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 403063.28 requests per second
GET: 508388.41 requests per second
影响 Redis 性能的因素
有几个因素直接决定 Redis 的性能。它们能够改变基准测试的结果， 所以我们必须注意到它们。一般情况下，Redis 默认参数已经可以提供足够的性能， 不需要调优。
- 网络带宽和延迟通常是最大短板。建议在基准测试之前使用 ping 来检查服务端到客户端的延迟。根据带宽，可以计算出最大吞吐量。 比如将 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么实际需要 3.2 Gbits/s 的带宽，所以需要 10 GBits/s 网络连接， 1 Gbits/s 是不够的。 在很多线上服务中，Redis 吞吐会先被网络带宽限制住，而不是 CPU。 为了达到高吞吐量突破 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 loopback。 当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。
- 当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。
其他需要注意的点
- 一个好的实践是尽可能在隔离的硬件上面测试。如果没法实现，那就需要检测 benchmark 没有受其他服务器活动影响。
- 有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 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）。
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second
