REDIS是使用客户端服务器模型和所谓的请求/响应协议的TCP服务器。这意味着该请求通常可以通过以下步骤完成：
因此，例如，四个命令序列如下所示：
客户端和服务器是通过网络链接连接的。链接可能非常快（环接口）或非常慢（内部两个主机之间有很多跳跃）。无需网络延迟，数据包将被传输从客户端到服务器一段时间，然后从服务器传输到客户端以进行答复。
这次称为rtt（圆形拖动时间）。很容易看出，当客户需要连续执行许多请求时（例如，在同一列表中添加多个元素，或在数据库中填写许多键），这将是影响性能。例如，如果RTT时间为250毫秒（当Internet上的链接非常慢时），即使服务器每秒可以处理100,000个请求，我们也可以每秒最多处理四个请求。
如果使用的接口是环返回接口，则RTT要短得多（例如，我的主机报告ping至127.0.0.1，0.044毫秒），但是如果您需要多次继续操作，则仍然有很多RTT。
幸运的是，有一种改善此案的方法。
它可以实现请求/响应服务器，以便即使客户端尚未读取旧响应，也可以处理新的请求。这样，可以将多个命令发送到服务器，您无需等待有关答复，您可以在最后一步中阅读答案。
这称为装配线，数十年来一直是广泛的技术。例如，许多POP3协议支持此功能，这极大地加速了从服务器下载新电子邮件的过程。
REDIS以来就一直支持管道传输，因此无论您运行哪个版本，都可以在Redis中使用管道传输。这是使用原始NetCat实用程序的示例：
这次，我们不必为每个呼叫支付RTT费用，而仅支付这三个命令。要明确，汇编行的第一个示例的第一个示例的操作顺序如下：
重要说明：当客户端使用装配线发送命令时，服务器将被迫使用内存来提起。因此，如果您需要使用管道发送大量命令，则最好将它们发送到一个合理的数量批处理处理方法，例如10K命令，读取答案，然后再次发送10K命令。速度几乎相同，但是所使用的额外内存将最大程度地增加对10K命令的最大响应数。
申报线传输不仅是降低往返行程成本的一种方法。实际上，它可以大大增加您可以在给定的Redis服务器中每秒执行的总运行量。这是由于以下事实：从访问数据结构和生成答案的角度来看，对于每个命令而无需使用汇编，它都非常便宜线路服务，但是从执行套接字I /。的角度来看，这是非常昂贵的，这涉及调用read（）和write（）系统调用，这意味着从用户域到内核域。ContextSwitching是巨大的速度损失。
使用汇编行时，通常调用一个读取（）系统来读取许多命令，并且通过单个写入（）系统调用了多个答案。管道，最终达到了未使用装配线的基准的10倍。从下图可以看到：
在下面的基准测试中，我们将使用Redis Ruby客户端，该客户端支持管道来进行测试，因为管道带来的速度提高：
运行上面的简单脚本将通过Mac OS X系统中的环接口提供以下数据。由于RTT已经很低，因此组装线方法将提供最小的改进：
如您所见，使用装配线，我们将将传输速度提高五次。
使用redis脚本（在Redis 2.6或更高版本中可用），您可以使用执行服务器所需的大量作业来更有效地求解许多汇编线。脚本编写的主要优点之一就是它可以使用最小延迟，以启用读，计算，写作等。（在这种情况下，流动水不可用，因为在阅读之前需要读取读取命令的客户端）。它可以调用写入命令）。
有时，应用程序可能还希望在管道中发送estal或evalsha命令。这是完全可能的。REDIS使用脚本加载命令明确支持它（它可以保证可以在不会失败的情况下调用Evalsha）。
即使此页面涵盖了所有背景，您仍然可能要知道，即使服务器和客户端在戒指的同一物理计算机上运行时，REDIS参考测试（伪代码）也仍然非常非常慢的：
毕竟，如果Redis进程和基准测试在同一框中运行，这不是将消息从一个地方复制到另一个地方而没有任何实际延迟和实际网络？
原因是系统中的过程并不总是运行。实际上，允许该过程运行的内核调度程序。并编写一个新命令。该命令现在位于戒指返回接口缓冲区中，但是为了让服务器读取，内核应安排服务器进程（当前在系统调用中被阻止），等等。实际上，由于内核调度程序的工作原理，循环接口仍然涉及类似于网络的延迟。
基本上，当可以测量网络服务器中的性能时，繁忙的基准测试是可以完成的最简单的事情。明智的方法是以这种方式避免基准测试。