Skip to content
This repository
Browse code

Refreshed benchmark page.

(mentioned new pipeline option, ethernet packet size impact, etc ...)
  • Loading branch information...
commit 65a3c8c2ca43c3f9bca01f7c0e796befdeae14b5 1 parent dbea346
Didier Spezia dspezia authored
BIN  topics/Data_size.png
69 topics/benchmarks.md
Source Rendered
@@ -9,23 +9,27 @@ The following options are supported:
9 9
10 10 Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]
11 11
12   - -h <hostname> Server hostname (default 127.0.0.1)
13   - -p <port> Server port (default 6379)
14   - -s <socket> Server socket (overrides host and port)
15   - -c <clients> Number of parallel connections (default 50)
16   - -n <requests> Total number of requests (default 10000)
17   - -d <size> Data size of SET/GET value in bytes (default 2)
18   - -k <boolean> 1=keep alive 0=reconnect (default 1)
19   - -r <keyspacelen> Use random keys for SET/GET/INCR, random values for SADD
  12 + -h <hostname> Server hostname (default 127.0.0.1)
  13 + -p <port> Server port (default 6379)
  14 + -s <socket> Server socket (overrides host and port)
  15 + -c <clients> Number of parallel connections (default 50)
  16 + -n <requests> Total number of requests (default 10000)
  17 + -d <size> Data size of SET/GET value in bytes (default 2)
  18 + -k <boolean> 1=keep alive 0=reconnect (default 1)
  19 + -r <keyspacelen> Use random keys for SET/GET/INCR, random values for SADD
20 20 Using this option the benchmark will get/set keys
21   - in the form mykey_rand000000012456 instead of constant
  21 + in the form mykey_rand:000000012456 instead of constant
22 22 keys, the <keyspacelen> argument determines the max
23 23 number of values for the random number. For instance
24   - if set to 10 only rand000000000000 - rand000000000009
  24 + if set to 10 only rand:000000000000 - rand:000000000009
25 25 range will be allowed.
26   - -q Quiet. Just show query/sec values
27   - -l Loop. Run the tests forever
28   - -I Idle mode. Just open N idle connections and wait.
  26 + -P <numreq> Pipeline <numreq> requests. Default 1 (no pipeline).
  27 + -q Quiet. Just show query/sec values
  28 + --csv Output in CSV format
  29 + -l Loop. Run the tests forever
  30 + -t <tests> Only run the comma separated list of tests. The test
  31 + names are the same as the ones produced as output.
  32 + -I Idle mode. Just open N idle connections and wait.
29 33
30 34 You need to have a running Redis instance before launching the benchmark.
31 35 A typical example would be:
@@ -65,11 +69,6 @@ multiple CPU cores. People are supposed to launch several Redis instances to
65 69 scale out on several cores if needed. It is not really fair to compare one
66 70 single Redis instance to a multi-threaded data store.
67 71
68   -Then the benchmark should do the same operations, and work in the same way with
69   -the multiple data stores you want to compare. It is absolutely pointless to
70   -compare the result of redis-benchmark to the result of another benchmark
71   -program and extrapolate.
72   -
73 72 A common misconception is that redis-benchmark is designed to make Redis
74 73 performances look stellar, the throughput achieved by redis-benchmark being
75 74 somewhat artificial, and not achievable by a real application. This is
@@ -77,13 +76,23 @@ actually plain wrong.
77 76
78 77 The redis-benchmark program is a quick and useful way to get some figures and
79 78 evaluate the performance of a Redis instance on a given hardware. However,
80   -it does not represent the maximum throughput a Redis instance can sustain.
81   -Actually, by using pipelining and a fast client (hiredis), it is fairly easy
82   -to write a program generating more throughput than redis-benchmark. The current
83   -version of redis-benchmark achieves throughput by exploiting concurrency only
84   -(i.e. it creates several connections to the server). It does not use pipelining
85   -or any parallelism at all (one pending query per connection at most, and
86   -no multi-threading).
  79 +by default, it does not represent the maximum throughput a Redis instance can
  80 +sustain. Actually, by using pipelining and a fast client (hiredis), it is fairly
  81 +easy to write a program generating more throughput than redis-benchmark. The
  82 +default behavior of redis-benchmark is to achieve throughput by exploiting
  83 +concurrency only (i.e. it creates several connections to the server).
  84 +It does not use pipelining or any parallelism at all (one pending query per
  85 +connection at most, and no multi-threading).
  86 +
  87 +To run a benchmark using pipelining mode (and achieve higher throughputs),
  88 +you need to explicitly use the -P option. Please note that it is still a
  89 +realistic behavior since a lot of Redis based applications actively use
  90 +pipelining to improve performance.
  91 +
  92 +Finally, the benchmark should apply the same operations, and work in the same way
  93 +with the multiple data stores you want to compare. It is absolutely pointless to
  94 +compare the result of redis-benchmark to the result of another benchmark
  95 +program and extrapolate.
87 96
88 97 For instance, Redis and memcached in single-threaded mode can be compared on
89 98 GET/SET operations. Both are in-memory data stores, working mostly in the same
@@ -153,6 +162,16 @@ the TCP/IP loopback and unix domain sockets can be used. It depends on the
153 162 platform, but unix domain sockets can achieve around 50% more throughput than
154 163 the TCP/IP loopback (on Linux for instance). The default behavior of
155 164 redis-benchmark is to use the TCP/IP loopback.
  165 ++ The performance benefit of unix domain sockets compared to TCP/IP loopback
  166 +tends to decrease when pipelining is heavily used (i.e. long pipelines).
  167 ++ When an ethernet network is used to access Redis, aggregating commands using
  168 +pipelining is especially efficient when the size of the data is kept under
  169 +the ethernet packet size (about 1500 bytes). Actually, processing 10 bytes,
  170 +100 bytes, or 1000 bytes queries almost result in the same throughput.
  171 +See the graph below.
  172 +
  173 +![Data size impact](https://github.com/dspezia/redis-doc/raw/6374a07f93e867353e5e946c1e39a573dfc83f6c/topics/Data_size.png.gif)
  174 +
156 175 + On multi CPU sockets servers, Redis performance becomes dependant on the
157 176 NUMA configuration and process location. The most visible effect is that
158 177 redis-benchmark results seem non deterministic because client and server

0 comments on commit 65a3c8c

Please sign in to comment.
Something went wrong with that request. Please try again.