Redis tutorial 02 -- Pipeline)

Request/response protocol and RTT

Redis is a client/server model (also calledRequest/ResponseProtocol.

This indicates that the implementation of one request involves the following steps:

• The client sends a request to the server and reads the server response data in a blocked manner from the socket.
The server processes the commands and sends the response data back to the client.

For example, sending four consecutive commands will look like this:

• Client:Incr x
• Server:1
• Client:Incr x
• Server:2
• Client:Incr x
• Server:3
• Client:Incr x
• Server:4

The client and server are connected over the network. This connection may be very fast (local loopback interface) or very slow (two hosts with many hops on the Internet ). Regardless of the network latency, data packets are sent from the client to the server and returned from the server to the client at a time.

This time is called the Loop Time. Obviously, when a client needs to send many requests at a time (for example, adding many elements to a list at a time or adding many keys to a database ), this loop time will have a significant impact on performance. If the Loop Time is 250 milliseconds (when the network connection is very slow), even if the server can process 0.1 million requests per second, we can process up to four requests per second.

Even if we use the local loopback interface, the local loop time will be much shorter (for example, the ping test on my local machine is 0.044 milliseconds), but if you want to perform a large number of write operations at a time, this time is still quite a lot.

Fortunately, we have a way to optimize this scenario.

Redis Pipeline

A request/response server can process new requests when the client has not read the previous return value. In this way, the client can send a message to the server without obtaining the response of each request.Multiple commandsAnd get all these responses at a time in the future.

This is called pipeline. This technology has been widely used many years ago. For example, many POP3 protocol implementations support pipelines, greatly improving the speed of downloading new emails from servers.

Redis supports pipelines very early, so no matter what version you are using, you can use pipelines in redis. The following is an example of using the native Netcat tool:

$ (echo -en "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379+PONG+PONG+PONG

This time, we don't incur RTT costs every time we call it. All commands add up to only generate RTT costs once.

To be very explicit, with pipelining the order of operations of our very first example will be the following:

In the first example, operations are performed in the following order if pipelines are used:

• Client:Incr x
• Client:Incr x
• Client:Incr x
• Client:Incr x
• Server:1
• Server:2
• Server:3
• Server:4

Note: When the client uses a pipeline to send multiple commands, the server puts all the responses in the queue, which leads to additional memory overhead. Therefore, if you want to use pipelines to send multiple commands at a time, you 'd better give a reasonable upper limit of the number of commands, such as 10000 commands, and then read the response, then, the system sends another 10000 commands and repeats them. In this way, the request speed will not change significantly, but the usage of the additional memory will only be equivalent to the upper limit required for caching the 10000 replies.

Performance indicators

In the following performance tests, we will use the redis Ruby client and pipeline to test the pipeline's speed improvement:

require ‘rubygems‘require ‘redis‘def bench(descr)    start = Time.now    yield    puts "#{descr} #{Time.now-start} seconds"enddef without_pipelining    r = Redis.new    10000.times {        r.ping    }enddef with_pipelining    r = Redis.new    r.pipelined {        10000.times {            r.ping        }    }endbench("without pipelining") {    without_pipelining}bench("with pipelining") {    with_pipelining}

Running the above simple script can provide some performance indicators on Mac OS X. Because the delay only comes from the local loopback interface, the RTT time is very short, the pipeline mechanism only provides the minimum performance improvement:

without pipelining 1.185238 secondswith pipelining 0.250783 seconds

It can be seen that pipeline performance has improved by five times.

MPs queue vs script

Because the script is executed on the server, using the redis script (which can be used for redis2.6 or later) can make some originally used pipelines run more efficiently. A major advantage of a script is that its read/write operation delay is quite small, so it canRead, compute, writeSuch operations are executed very quickly (the pipeline performs poorly in this scenario, because the pipeline needs to get the Read Request Response and return value before executing the write operation ).

In some cases, the application may want to send the evla or evalsha command through the pipeline. This is completely feasible, and redis explicitly supports this operation through the script load command (and ensures that the evalsha operation will not fail ).

Redis tutorial 02 -- Pipeline)