当用户连接到Redis通过TCP/IP连接或Unix域连接，千兆网 络的典型延迟大概200us，而Unix域socket可能低到30us。这完全基于你的网络和系统硬件。在通信本身之上，系统增加了更多的延迟(线程调 度，CPU缓存，NUMA替换等等)。系统引起的延迟在虚拟机环境远远高于在物理机器环境。

　　实际情况是即使Redis处理大多数命令在微秒之下，客户机和服务器之间的交互也必然消耗系统相关的延迟。

　　一个高效的客户机因而试图通过捆绑多个命令在一起的方式减少交互的次数。服务器和大多数客户机支持这种方式。聚合命令象MSET/MGET也可以用作这个目的。从Redis 2.4版本起，很多命令对于所有的数据类型也支持可变参数。

　　这里有一些指导：

• 如果你负担的起，尽可能的使用物理机而不是虚拟机来做服务器
• 不要经常的connect/disconnect与服务器的连接(尤其是对基于web的应用)，尽可能的延长与服务器连接的时间。
• 如果你的客户端和服务器在同一台主机上，则使用Unix域套接字
• 尽量使用聚合命令(MSET/MGET)或可变参数命令而不是pipelining
• 如果可以尽量使用pipelining而不是序列的往返命令。
• 针对不适合使用原始pipelining的情况，如某个命令的结果是后续命令的输入，在以后的版本中redis提供了对服务器端的lua脚本的支持，实验分支版本现在已经可以使用了。

　 　在Linux上，你可以通过process placement(taskset)、cgroups、real-time priorities(chrt)、NUMA配置(numactl)或使用低延迟内核的方式来获取较低的延迟。请注意Redis 并不适合被绑到单个CPU核上。redis会在后台创建一些非常消耗CPU的进程，如bgsave和AOF重写，这些任务是绝对不能和主事件循环进程放在 一个CPU核上的。

　　大多数情况下上述的优化方法是不需要的，除非你确实需要并且你对优化方法很熟悉的情况下再使用上述方法。

　　Redis 使用了单线程的设计， 意味着单线程服务于所有的客户端请求，使用一种复用的技术。这种情况下redis可以在任何时候处理单个请求， 所以所有的请求是顺序处理的。这和Node.js的工作方式很像， 所有的产出通常不会有慢的感觉，因为处理单个请求的时间非常短，但是最重要的是这些产品被设计为非阻塞系统调用，比如从套接字中读取或写入数据。

　　我提到过Redis从2.4版本后几乎是单线程的，我们使用线程在后台运行一些效率低下的I/O操作， 主要关系到硬盘I/O，但是这不改变Redis使用单线程处理所有请求的事实。

　　低效操作产生的延迟

　　单线程的一个结果是，当一个请求执行得很慢，其他的客 户端调用就必须等待这个请求执行完毕。当执行GET、SET或者LPUSH 命令的时候这不是个问题，因为这些操作可在很短的常数时间内完成。然而，对于多个元素的操作，像SORT,LREM, SUNION 这些，做两个大数据集的交叉要花掉很长的时间。

　　文档中提到了所有操作的算法复杂性。 在使用一个你不熟悉的命令之前系统的检查它会是一个好办法。

　　如果你对延迟有要求，那么就不要执行涉及多个元素的慢操作，你可以使用Redis的replication功能，把这类慢操作全都放到replica上执行。

　　可以用Redis 的Slow Log来监控慢操作。

　　此外，你可以用你喜欢的进程监控程序(top, htop, prstat, 等...)来快速查看Redis进程的CPU使用率。如果traffic不高而CPU占用很高，八成说明有慢操作。

　　延迟由fork产生

　 　Redis不论是为了在后台生成一个RDB文件，还是为了当AOF持久化方案被开启时重写Append Only文件，都会在后台fork出一个进程。fork操作(在主线程中被执行)本身会引发延迟。在大多数的类unix操作系统中，fork是一个很消耗 的操作，因为它牵涉到复制很多与进程相关的对象。而这对于分页表与虚拟内存机制关联的系统尤为明显

　　对于运行在一个 linux/AMD64系统上的实例来说，内存会按照每页4KB的大小分页。为了实现虚拟地址到物理地址的转换，每一个进程将会存储一个分页表(树状形式 表现)，分页表将至少包含一个指向该进程地址空间的指针。所以一个空间大小为24GB的redis实例，需要的分页表大小为 24GB/4KB*8 = 48MB。

　　当一个后台的save命令执行时，实例会启动新的线程去申请和拷贝48MB的内存空间。这将消耗一些时间和CPU资源，尤其是在虚拟机上申请和初始化大块内存空间时，消耗更加明显。

　　在不同系统中的Fork时间

　 　除了Xen系统外，现代的硬件都可以快速完美的复制页表。Xen系统的问题不是特定的虚拟化，而是特定的Xen.例如使用VMware或者 Virutal Box不会导致较慢的fork时间。下面的列表比较了不同Redis实例的fork时间。数据包含正在执行的BGSAVE，并通过INFO指令查看 thelatest_fork_usecfiled。

• Linux beefy VM on VMware 6.0GB RSS forked 77 微秒 (每GB 12.8 微秒 ).
• Linux running on physical machine (Unknown HW) 6.1GB RSS forked 80 微秒(每GB 13.1微秒)
• Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 微秒 (每GB 9 微秒).
• Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 微秒 (每GB 23.3 微秒).
• Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 微秒 (每GB 239.3 微秒).
• Linux VM on Linode (Xen) 0.9GBRSS forked into 382 微秒 (每GB 424 微秒).

　　你能看到运行在Xen上的VM的Redis性能相差了一到两个数量级。我们相信这是Xen系统的一个验证问题，我们希望这个问题能尽快处理。

　　swapping (操作系统分页)引起的延迟

　　Linux (以及其他一些操作系统) 可以把内存页存储在硬盘上，反之也能将存储在硬盘上的内存页再加载进内存，这种机制使得内存能够得到更有效的利用。

　　如果内存页被系统移到了swap文件里，而这个内存页中的数据恰好又被redis用到了(例如要访问某个存储在内存页中的key)，系统就会暂停redis进程直到把需要的页数据重新加载进内存。这个操作因为牵涉到随机I/O，所以很慢，会导致无法预料的延迟。

　　系统之所以要在内存和硬盘之间置换redis页数据主要因为以下三个原因：

• 系统总是要应对内存不足的压力，因为每个运行的进程都想申请更多的物理内存，而这些申请的内存的数量往往超过了实际拥有的内存。简单来说就是redis使用的内存总是比可用的内存数量更多。
• redis实例的数据，或者部分数据可能就不会被客户端访问，所以系统可以把这部分闲置的数据置换到硬盘上。需要把所有数据都保存在内存中的情况是非常罕见的。
• 一些进程会产生大量的读写I/O。因为文件通常都有缓存，这往往会导致文件缓存不断增加，然后产生交换(swap)。请注意，redis RDB和AOF后台线程都会产生大量文件。

　　所幸Linux提供了很好的工具来诊断这个问题，所以当延迟疑似是swap引起的，最简单的办法就是使用Linux提供的工具去确诊。

　　首先要做的是检查swap到硬盘上的redis内存的数量，为实现这个目的要知道redis实例的进程id：

　　在这里你会发现一个名为smaps 的文件，它描述了redis进程的内存布局 (假定你使用的是Linux 2.6.16或者更新的版本)。这个文件包括了很多进程所使用内存的细节信息，其中有一项叫做Swap的正是我们所关心的。不过仅看这一项是不够的，因为 smaps文件包括有redis进程的多个不同的的内存映射区域的使用情况(进程的内存布局远不是线性排列那么简单)。

　　从我们对所有进程的内存交换情况感兴趣以来，我们首先要做的事情是使用grep命令显示进程的smaps文件

　　最后，可以用iostat命令来查看系统的全局I/O行为。

　　上面的命令会展示redis主线程里所有的fdatasync系统调用。不包括后台线程执行的fdatasync 调用。如果appendfsync 配置为everysec，则给strace增加-f选项。

　　用下面命令可以看到fdatasync和write调用：

　　在所有的情况下，一旦Redis运行huge page(透明或者非透明)，将会得到如下的好处：

• 由于fork引起的延迟将得到缓解。尤其是对超大的实例，尤其是在VM上运行的实例。
• Redis速度得到提够，是因为CPU的转换旁视缓冲(TLB)更有效的缓存页面(例如命中率会更高)。不要期望有奇迹发生，性能至多只能提高一点。
• Redis内存不会再被换走，这样就能避免由于虚拟内存造成的不必的延迟。

　 　很不幸，除了更多的复杂操作，还有redis使用huge page会带来一个明显的缺陷。COW机制的粒度是页面。伴随2MB页面，页面被后台存储操作修改的可能性是4KB页面的512倍。实际的内存需要后台存 储，所以可能性会增加很多，尤其是，当写操作很随机，并且伴随很差的定位。通过huge page，使用两倍的内存，而存储将不再是理论的突发事件。它真的会发生。

　　完整的性能评估结果可以参阅链接：https://gist.github.com/1272254