<div class="text">

How fast is Redis?

Redis includes the redis-benchmark utility that simulates running commands done by N clients at the same time sending M total queries (it is similar to the Apache's ab utility). Below you'll find the full output of a benchmark executed against a Linux box.

The following options are supported:

Usage: redis-benchmark [-h ] [-p ] [-c ] [-n  [-k ]
-h       Server hostname (default 127.0.0.1)

-p           Server port (default 6379)

-s         Server socket (overrides host and port)

-c        Number of parallel connections (default 50)

-n       Total number of requests (default 10000)

-d           Data size of SET/GET value in bytes (default 2)

-k        1=keep alive 0=reconnect (default 1)

-r    Use random keys for SET/GET/INCR,random values for SADD

Using this option the benchmark will get/set keys

in the form mykey_rand:000000012456 instead of constant

keys,the  argument determines the max

number of values for the random number. For instance

if set to 10 only rand:000000000000 - rand:000000000009

range will be allowed.

-P         Pipeline  requests. Default 1 (no pipeline).

-q                 Quiet. Just show query/sec values

--csv              Output in CSV format

-l                 Loop. Run the tests forever

-t          Only run the comma separated list of tests. The test

names are the same as the ones produced as output.

-I                 Idle mode. Just open N idle connections and wait.

You need to have a running Redis instance before launching the benchmark. A typical example would be:

redis-benchmark -q -n 100000

Using this tool is quite easy,and you can also write your own benchmark,but as with any benchmarking activity,there are some pitfalls to avoid.

Running only a subset of the tests

You don't need to run all the default tests every time you execute redis-benchmark. The simplest thing to select only a subset of tests is to use the -t option like in the following example:

$ redis-benchmark -t set,lpush -n 100000 -q
SET: 74239.05 requests per second
LPUSH: 79239.30 requests per second

In the above example we asked to just run test the SET and LPUSH commands,in quite mode (see the -q switch).

It is also possible to specify the command to benchmark directly like in the following example:

$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','bar'): 69881.20 requests per second

Selecting the size of the key space

By default the benchmark runs against a single key. In Redis the difference between such a synthetic benchmark and a real one is not huge since it is an in memory system,however it is possible to stress cache misses and in general to simulate a more real-world work load by using a large key space.

This is obtained by using the -r switch. For instance if I want to run one million of SET operations,using a random key for every operation out of 100k possible keys,I'll use the following command line:

$ redis-cli flushall
OK
$ redis-benchmark -t set -r 100000 -n 1000000

====== SET ======

1000000 requests completed in 13.86 seconds

50 parallel clients

3 bytes payload

keep alive: 1
99.76% <= 1 milliseconds

99.98% <= 2 milliseconds

100.00% <= 3 milliseconds

100.00% <= 3 milliseconds

72144.87 requests per second
$ redis-cli dbsize

(integer) 99993

Using pipelining

By default every client (the benchmark simulates 50 clients if not otherwise specified with -c) sends the next command only when the reply of the previous command is received,this means that the server will likely need a read call in order to read each command from every client. Also RTT is payed as well.

Redis supports ,so it is possible to send multiple commands at once,a feature often exploited by real world applications. Redis pipelining is able to dramatically improve the number of operations per second a server is able do deliver.

This is an example of running the benchmark in a Macbook air 11" using a pipeling of 16 commands:

$ redis-benchmark -n 1000000 -t set,get -P 16 -q
SET: 403063.28 requests per second
GET: 508388.41 requests per second

Using pipelining resulted into a sensible amount of more commands processed.

Pitfalls and misconceptions

The first point is obvious: the golden rule of a useful benchmark is to only compare apples and apples. Different versions of Redis can be compared on the same workload for instance. Or the same version of Redis,but with different options. If you plan to compare Redis to something else,then it is important to evaluate the functional and technical differences,and take them in account.

• Redis is a server: all commands involve network or IPC roundtrips. It is meaningless to compare it to embedded data stores such as SQLite,Berkeley DB,Tokyo/Kyoto Cabinet,etc ... because the cost of most operations is precisely dominated by network/protocol management.
• Redis commands return an acknowledgment for all usual commands. Some other data stores do not (for instance MongoDB does not implicitly acknowledge write operations). Comparing Redis to stores involving one-way queries is only mildly useful.
• Naively iterating on synchronous Redis commands does not benchmark Redis itself,but rather measure your network (or IPC) latency. To really test Redis,you need multiple connections (like redis-benchmark) and/or to use pipelining to aggregate several commands and/or multiple threads or processes.
• Redis is an in-memory data store with some optional persistency options. If you plan to compare it to transactional servers (MySQL,PostgreSQL,etc ...),then you should consider activating AOF and decide of a suitable fsync policy.
• Redis is a single-threaded server. It is not designed to benefit from multiple CPU cores. People are supposed to launch several Redis instances to scale out on several cores if needed. It is not really fair to compare one single Redis instance to a multi-threaded data store.

A common misconception is that redis-benchmark is designed to make Redis performances look stellar,the throughput achieved by redis-benchmark being somewhat artificial,and not achievable by a real application. This is actually plain wrong.

The redis-benchmark program is a quick and useful way to get some figures and evaluate the performance of a Redis instance on a given hardware. However,by default,it does not represent the maximum throughput a Redis instance can sustain. Actually,by using pipelining and a fast client (hiredis),it is fairly easy to write a program generating more throughput than redis-benchmark. The default behavior of redis-benchmark is to achieve throughput by exploiting concurrency only (i.e. it creates several connections to the server). It does not use pipelining or any parallelism at all (one pending query per connection at most,and no multi-threading).

To run a benchmark using pipelining mode (and achieve higher throughputs),you need to explicitly use the -P option. Please note that it is still a realistic behavior since a lot of Redis based applications actively use pipelining to improve performance.

Finally,the benchmark should apply the same operations,and work in the same way with the multiple data stores you want to compare. It is absolutely pointless to compare the result of redis-benchmark to the result of another benchmark program and extrapolate.

For instance,Redis and memcached in single-threaded mode can be compared on GET/SET operations. Both are in-memory data stores,working mostly in the same way at the protocol level. Provided their respective benchmark application is aggregating queries in the same way (pipelining) and use a similar number of connections,the comparison is actually meaningful.

This perfect example is illustrated by the dialog between Redis (antirez) and memcached (dormando) developers.

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!