4.5 Non-transactional pipelines
When we first introduced MULTI/EXEC in chapter 3, we talked about them as having a
“transaction” property—everything between the MULTI and EXEC commands will execute
without other clients being able to do anything. One benefit to using transactions is the underlying library’s use of a pipeline, which improves performance. This section
will show how to use a pipeline without a transaction to further improve performance.
You’ll remember from chapter 2 that some commands take multiple arguments for
adding/updating—commands like MGET, MSET, HMGET, HMSET, RPUSH/LPUSH, SADD, ZADD, and others. Those commands exist to streamline calls to perform the same operation
repeatedly. As you saw in chapter 2, this can result in significant performance
improvements. Though not as drastic as these commands, the use of non-transactional
pipelines offers many of the same performance advantages, and allows us to run
a variety of commands at the same time.
In the case where we don’t need transactions, but where we still want to do a lot of
work, we could still use MULTI/EXEC for their ability to send all of the commands at the
same time to minimize round trips and latency. Unfortunately, MULTI and EXEC aren’t
free, and can delay other important commands from executing. But we can gain all the
benefits of pipelining without using MULTI/EXEC. When we used MULTI/EXEC in Python
in chapter 3 and in section 4.4, you may have noticed that we did the following:
By passing True to the pipeline() method (or omitting it), we’re telling our client to
wrap the sequence of commands that we’ll call with a MULTI/EXEC pair. If instead of
passing True we were to pass False, we’d get an object that prepared and collected
commands to execute similar to the transactional pipeline, only it wouldn’t be
wrapped with MULTI/EXEC. For situations where we want to send more than one command
to Redis, the result of one command doesn’t affect the input to another, and we
don’t need them all to execute transactionally, passing False to the pipeline()
method can further improve overall Redis performance. Let’s look at an example.
Way back in sections 2.1 and 2.5, we wrote and updated a function called
update_token(), which kept a record of recent items viewed and recent pages viewed,
and kept the user’s login cookie updated. The updated code from section 2.5 is shown
in listing 4.7. Note how the function will make three or five calls to Redis for every call
of the function. As written, that will result in three or five round trips between Redis
and our client.
If our Redis and web servers are connected over LAN with only one or two steps, we could
expect that the round trip between the web server and Redis would be around 1–2 milliseconds.
With three to five round trips between Redis and the web server, we could
expect that it would take 3–10 milliseconds for update_token() to execute. At that
speed, we could only expect a single web server thread to be able to handle 100–333
requests per second. This is great, but we could do better. Let’s quickly create a nontransactional
pipeline and make all of our requests over that pipeline. You can see the
updated function in the next listing.
By replacing our standard Redis connection with a pipelined connection, we can
reduce our number of round trips by a factor of 3–5, and reduce the expected time to
execute update_token_pipeline() to 1–2 milliseconds. At that speed, a single web
server thread could handle 500–1000 requests per second if it only had to deal with
updating item view information. Theoretically, this is great, but what about in reality?
Let’s test both of these functions by performing a simple benchmark. We’ll test the
number of requests that can be processed per second against a copy of Redis that’s on
the same machine, across a fast and low-latency network connection, and across a slow
and higher latency connection. We’ll first start with the benchmark code that we’ll use
to test the performance of these connections. In our benchmark, we’ll call either
update_token() or update_token_pipeline() repeatedly until we reach a prespecified
timeout, and then calculate the number of requests we can service at a given time. The
following listing shows the code that we’ll use to run our two update_token commands.
When we run the benchmark function across a variety of connections with the given
available bandwidth (gigabits or megabits) and latencies, we get data as shown in
update_table() calls per second
Local machine, Unix domain socket
Local machine, localhost
Remote machine, shared switch
Remote machine, connected through VPN
Looking at the table, note that for high-latency connections, we can multiply performance
by a factor of five using pipelines over not using pipelines. Even with very lowlatency
remote connections, we’re able to improve performance by almost four times.
For local connections, we actually run into the single-core performance limit of
Python sending and receiving short command sequences using the Redis protocol
(we’ll talk about this more in section 4.6).
You now know how to push Redis to perform better without transactions. Beyond
using pipelines, are there any other standard ways of improving the performance of