Redis Tutorial (13): Pipeline detailed _redis

A. Request answer agreement and RTT:

Redis is a typical TCP server based on the C/S model. In the communication process between the client and the server, the client usually takes the lead in initiating the request, the server performs the corresponding task after receiving the request, and finally sends the acquired data or processing result to the client in the way of answering. In this procedure, the client waits in a blocked way for the results returned by the server. See the following command sequence:

Copy Code code as follows:

CLIENT:INCR X
Server:1
CLIENT:INCR X
Server:2
CLIENT:INCR X
Server:3
CLIENT:INCR X
Server:4

In every request and response process, we have to bear the extra overhead of network transmission. We typically refer to this overhead as the RTT (Round trip time). Now we assume that the RTT for each request and answer is 250 milliseconds, and our server can process 100k of data in one second, and the result is that our server processes up to 4 requests per second. What can we do to optimize this performance problem?

second, Pipeline (pipelining):

Redis has provided support for the command pipeline in a very early release. Before giving a specific explanation, we first change the above example of synchronous response to an asynchronous response based on the command line, so that we can have a better perceptual knowledge.

Copy Code code as follows:

CLIENT:INCR X
CLIENT:INCR X
CLIENT:INCR X
CLIENT:INCR X
Server:1
Server:2
Server:3
Server:4

As you can see from the example above, the client does not have to wait for a reply from the server immediately after sending the command, but can continue to send the following command. Once the command has been sent, the answer to all previous commands is read again. This saves the cost of RTT in the sync mode.
Finally, if the Redis server discovers that the client's request is based on a pipeline, the server side, after accepting the request and processing, stores the reply data for each command in the queue before sending it to the client.

Third, Benchmark:

Here are the test cases and test results from the Redis website. It should be explained that the test is based on loopback (127.0.0.1), so the RTT takes a relatively small amount of time, and if it is based on the actual network interface, then the performance improvement of the pipeline mechanism is even more significant.

Copy Code code as follows:

Require ' RubyGems '
Require ' Redis '

def bench (DESCR)
Start = Time.now
Yield
Puts "#{descr} #{time.now-start} seconds"
End

def without_pipelining
r = Redis.new
10000.times {
R.ping
}
End

def with_pipelining
r = Redis.new
r.pipelined {
10000.times {
R.ping
}
}
End

Bench ("without pipelining") {
Without_pipelining
}
Bench ("with pipelining") {
With_pipelining
}
Without pipelining 1.185238 seconds
With pipelining 0.250783 seconds