[redis.git] / doc / RedisPipelining.html


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
    <head>
        <link type="text/css" rel="stylesheet" href="style.css" />
    </head>
    <body>
        <div id="page">
        
            <div id='header'>
            <a href="index.html">
            <img style="border:none" alt="Redis Documentation" src="redis.png">
            </a>
            </div>
        
            <div id="pagecontent">
                <div class="index">
<!-- This is a (PRE) block.  Make sure it's left aligned or your toc title will be off. -->
<b>RedisPipelining: Contents</b><br>&nbsp;&nbsp;<a href="#Request/Response protocols and RTT">Request/Response protocols and RTT</a><br>&nbsp;&nbsp;<a href="#Redis Pipelining">Redis Pipelining</a><br>&nbsp;&nbsp;<a href="#Some benchmark">Some benchmark</a><br>&nbsp;&nbsp;<a href="#Pipelining VS other multi-commands">Pipelining VS other multi-commands</a>
                </div>
                
                <h1 class="wikiname">RedisPipelining</h1>

                <div class="summary">
                    
                </div>

                <div class="narrow">
                    <h1><a name="Request/Response protocols and RTT">Request/Response protocols and RTT</a></h1>
Redis is a TCP server using the client-server model and what is called a <b>Request/Response</b> protocol.<br/><br/>This means that usually a request is accomplished with the following steps:
<ul><li> The client sends a query to the server, and reads from the socket, usually in a blocking way, for the server response.</li><li> The server processes the command and sends the response back to the server.</li></ul>So for instance a four commands sequence is something like this:
<ul><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 1</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 2</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 3</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 4</li></ul>Clients and Servers are connected via a networking link. Such a link can be very fast (a loopback interface) or very slow (a connection established over the internet with many hops between the two hosts). Whatever the network latency is, there is a time for the packets to travel from the client to the server, and back from the server to the client to carry the reply.<br/><br/>This time is called RTT (Round Trip Time). It is very easy to see how this can affect the performances when a client needs to perform many requests in a row (for instance adding many elements to the same list, or populating a database with many keys). For instance if the RTT time is 250 milliseconds (in the case of a very slow link over the internet), even if the server is able to process 100k requests per second, we'll be able to process at max four requests per second.<br/><br/>If the interface used is a loopback interface, the RTT is much shorter (for instance my host reports 0,044 milliseconds pinging 127.0.0.1), but it is still a lot if you need to perform many writes in a row.<br/><br/>Fortunately there is a way to improve this use cases.
<h1><a name="Redis Pipelining">Redis Pipelining</a></h1>
A Request/Response server can be implemented so that it is able to process new requests even if the client didn't already read the old responses. This way it is possible to send <b>multiple commands</b> to the server without waiting for the replies at all, and finally read the replies in a single step.<br/><br/>This is called pipelining, and is a technique widely in use since many decades. For instance many POP3 protocol implementations already supported this feature, dramatically speeding up the process of downloading new emails from the server.<br/><br/>Redis supports pipelining since the very early days, so whatever version you are running, you can use pipelining with Redis. This is an example using the raw netcat utility:
<pre class="codeblock python" name="code">
$ (echo -en &quot;PING\r\nPING\r\nPING\r\n&quot;; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG
</pre>
This time we are not paying the cost of RTT for every call, but just one time for the three commands.<br/><br/>To be very explicit, with pipelining the order of operations of our very first example will be the following:
<ul><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 1</li><li> <b>Server:</b> 2</li><li> <b>Server:</b> 3</li><li> <b>Server:</b> 4</li></ul><b>IMPORTANT NOTE</b>: while the client sends commands using pipelining, the server will be forced to queue the replies, using memory. So if you need to send many many commands with pipelining it's better to send this commands up to a given reasonable number, for instance 10k commands, read the replies, and send again other 10k commands and so forth. The speed will be nearly the same, but the additional memory used will be at max the amount needed to queue the replies for this 10k commands.
<h1><a name="Some benchmark">Some benchmark</a></h1>
In the following benchmark we'll use the Redis Ruby client, supporting pipelining, to test the speed improvement due to pipelining:
<pre class="codeblock python python" name="code">
require 'rubygems'
require 'redis'

def bench(descr)
    start = Time.now
    yield
    puts &quot;#{descr} #{Time.now-start} seconds&quot;
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(&quot;without pipelining&quot;) {
    without_pipelining
}
bench(&quot;with pipelining&quot;) {
    with_pipelining
}
</pre>
Running the above simple script will provide this figures in my Mac OS X system, running over the loopback interface, where pipelining will provide the smallest improvement as the RTT is already pretty low:
<pre class="codeblock python python python" name="code">
without pipelining 1.185238 seconds
with pipelining 0.250783 seconds
</pre>
As you can see using pipelining we improved the transfer by a factor of five.
<h1><a name="Pipelining VS other multi-commands">Pipelining VS other multi-commands</a></h1>
Often we get requests about adding new commands performing multiple operations in a single pass.
For instance there is no command to add multiple elements in a set. You need calling many times SADD.<br/><br/>With pipelining you can have performances near to an MSADD command, but at the same time we'll avoid bloating the Redis command set with too many commands. An additional advantage is that the version written using just SADD will be ready for a distributed environment (for instance Redis Cluster, that is in the process of being developed) just dropping the pipelining code.
                </div>
        
            </div>
        </div>
    </body>
</html>
Commit	Line	Data
6674e3b9	1
	2	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
	3	<html>
	4	<head>
	5	<link type="text/css" rel="stylesheet" href="style.css" />
	6	</head>
	7	<body>
	8	<div id="page">
	9
	10	<div id='header'>
	11	<a href="index.html">
	12	<img style="border:none" alt="Redis Documentation" src="redis.png">
	13	</a>
	14	</div>
	15
	16	<div id="pagecontent">
	17	<div class="index">
	18	<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
	19	<b>RedisPipelining: Contents</b><br>  <a href="#Request/Response protocols and RTT">Request/Response protocols and RTT</a><br>  <a href="#Redis Pipelining">Redis Pipelining</a><br>  <a href="#Some benchmark">Some benchmark</a><br>  <a href="#Pipelining VS other multi-commands">Pipelining VS other multi-commands</a>
	20	</div>
	21
	22	<h1 class="wikiname">RedisPipelining</h1>
	23
	24	<div class="summary">
	25
	26	</div>
	27
	28	<div class="narrow">
	29	<h1><a name="Request/Response protocols and RTT">Request/Response protocols and RTT</a></h1>
	30	Redis is a TCP server using the client-server model and what is called a <b>Request/Response</b> protocol.<br/><br/>This means that usually a request is accomplished with the following steps:
	31	<ul><li> The client sends a query to the server, and reads from the socket, usually in a blocking way, for the server response.</li><li> The server processes the command and sends the response back to the server.</li></ul>So for instance a four commands sequence is something like this:
	32	<ul><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 1</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 2</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 3</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 4</li></ul>Clients and Servers are connected via a networking link. Such a link can be very fast (a loopback interface) or very slow (a connection established over the internet with many hops between the two hosts). Whatever the network latency is, there is a time for the packets to travel from the client to the server, and back from the server to the client to carry the reply.<br/><br/>This time is called RTT (Round Trip Time). It is very easy to see how this can affect the performances when a client needs to perform many requests in a row (for instance adding many elements to the same list, or populating a database with many keys). For instance if the RTT time is 250 milliseconds (in the case of a very slow link over the internet), even if the server is able to process 100k requests per second, we'll be able to process at max four requests per second.<br/><br/>If the interface used is a loopback interface, the RTT is much shorter (for instance my host reports 0,044 milliseconds pinging 127.0.0.1), but it is still a lot if you need to perform many writes in a row.<br/><br/>Fortunately there is a way to improve this use cases.
	33	<h1><a name="Redis Pipelining">Redis Pipelining</a></h1>
	34	A Request/Response server can be implemented so that it is able to process new requests even if the client didn't already read the old responses. This way it is possible to send <b>multiple commands</b> to the server without waiting for the replies at all, and finally read the replies in a single step.<br/><br/>This is called pipelining, and is a technique widely in use since many decades. For instance many POP3 protocol implementations already supported this feature, dramatically speeding up the process of downloading new emails from the server.<br/><br/>Redis supports pipelining since the very early days, so whatever version you are running, you can use pipelining with Redis. This is an example using the raw netcat utility:
	35	<pre class="codeblock python" name="code">
	36	$ (echo -en "PING\r\nPING\r\nPING\r\n"; sleep 1) \| nc localhost 6379
	37	+PONG
	38	+PONG
	39	+PONG
	40	</pre>
	41	This time we are not paying the cost of RTT for every call, but just one time for the three commands.<br/><br/>To be very explicit, with pipelining the order of operations of our very first example will be the following:
	42	<ul><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Client:</b> INCR X</li><li> <b>Server:</b> 1</li><li> <b>Server:</b> 2</li><li> <b>Server:</b> 3</li><li> <b>Server:</b> 4</li></ul><b>IMPORTANT NOTE</b>: while the client sends commands using pipelining, the server will be forced to queue the replies, using memory. So if you need to send many many commands with pipelining it's better to send this commands up to a given reasonable number, for instance 10k commands, read the replies, and send again other 10k commands and so forth. The speed will be nearly the same, but the additional memory used will be at max the amount needed to queue the replies for this 10k commands.
	43	<h1><a name="Some benchmark">Some benchmark</a></h1>
	44	In the following benchmark we'll use the Redis Ruby client, supporting pipelining, to test the speed improvement due to pipelining:
	45	<pre class="codeblock python python" name="code">
	46	require 'rubygems'
	47	require 'redis'
	48
	49	def bench(descr)
	50	start = Time.now
	51	yield
	52	puts "#{descr} #{Time.now-start} seconds"
	53	end
	54
	55	def without_pipelining
	56	r = Redis.new
	57	10000.times {
	58	r.ping
	59	}
	60	end
	61
	62	def with_pipelining
	63	r = Redis.new
	64	r.pipelined {
65	10000.times {
66	r.ping
67	}
68	}
69	end
70
71	bench("without pipelining") {
72	without_pipelining
73	}
74	bench("with pipelining") {
75	with_pipelining
76	}
77	</pre>
78	Running the above simple script will provide this figures in my Mac OS X system, running over the loopback interface, where pipelining will provide the smallest improvement as the RTT is already pretty low:
79	<pre class="codeblock python python python" name="code">
80	without pipelining 1.185238 seconds
81	with pipelining 0.250783 seconds
82	</pre>
83	As you can see using pipelining we improved the transfer by a factor of five.
84	<h1><a name="Pipelining VS other multi-commands">Pipelining VS other multi-commands</a></h1>
85	Often we get requests about adding new commands performing multiple operations in a single pass.
86	For instance there is no command to add multiple elements in a set. You need calling many times SADD.<br/><br/>With pipelining you can have performances near to an MSADD command, but at the same time we'll avoid bloating the Redis command set with too many commands. An additional advantage is that the version written using just SADD will be ready for a distributed environment (for instance Redis Cluster, that is in the process of being developed) just dropping the pipelining code.
87	</div>
88
89	</div>
90	</div>
91	</body>
92	</html>
93