How to check Redis benchmark parameters
- PHPzforward
- 2023-06-04 12:12:121586browse
Redis comes with a tool called redis-benchmark to simulate N clients issuing M requests at the same time. (similar to the Apacheab program). Use the command redis-benchmark -h to view the benchmark parameters.
以下参数被支持： Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests> [-k <boolean>] -h <hostname> Server hostname (default 127.0.0.1) -p <port> Server port (default 6379) -s <socket> Server socket (overrides host and port) -c <clients> Number of parallel connections (default 50) -n <requests> Total number of requests (default 10000) -d <size> Data size of SET/GET value in bytes (default 2) -k <boolean> 1=keep alive 0=reconnect (default 1) -r <keyspacelen> 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 <keyspacelen> 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 <numreq> Pipeline <numreq> requests. Default 1 (no pipeline). -q Quiet. Just show query/sec values --csv Output in CSV format -l Loop. Run the tests forever -t <tests> 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.</tests></numreq></numreq></keyspacelen></keyspacelen></boolean></size></requests></clients></socket></port></hostname></boolean></requests></clients></port></host>
You need to start a Redis instance before benchmarking. Generally, the test is started like this:
redis-benchmark -q -n 100000
This tool is very convenient to use, and you can use your own benchmark testing tool. However, when starting the benchmark test, we need to pay attention to some details.
Run only a subset of some test cases
It is not necessary to run all tests by default every time you run redis-benchmark. You can use the parameter "-t" to specify the test cases that need to be run, such as 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 test, we only ran the SET and LPUSH commands, and ran in quiet mode (using -q parameter).
You can also directly specify the command to run directly, such as the following example:
$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second
Select the range size of the test key
By default, the benchmark test uses a single key. In an in-memory database, there won't be a huge difference between the single key test and the real world. Of course, widening the key range can simulate real-world cache misses.
At this time we can use the -r command. For example, if we want to perform 1 million SET operations continuously, using 100,000 random keys each time, we can use the following command:
$ 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% `<h3>Use pipelining</h3><p>By default, each client The next request is sent only after one request is completed (the benchmark will simulate 50 clients unless a special number is specified with -c), which means that the server reads the commands of each client almost in sequence. Also RTT is paid as well.</p><p>The real world will be more complicated. Redis supports /topics/pipelining, making it possible to execute multiple commands at once. Use Redis pipelining to increase your server's transaction per second rate. </p><p>The following case is a test example of using pipelining to organize 16 commands on a Macbook air 11": </p><pre class="brush:php;toolbar:false">$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second
Remember to use pipelining when multiple commands need to be processed.
Traps and misunderstandings
The first point is obvious: the golden rule of benchmark testing is to use the same standard. When testing different versions of Redis, you can test with the same workload or use the same parameters. If you test Redis with other tools, you need to be careful about the differences in functional details.
Redis is a server: all commands include network or IPC consumption. This means that it and SQLite , Berkeley DB, Tokyo/Kyoto Cabinet, etc. are meaningless in comparison, because most of the consumption is on the network protocol.
Most of the common commands of Redis have confirmation returns. For example, MongoDB's write operations will not return confirmation, but some data storage systems will. It is not meaningful to compare Redis with other one-way call command storage systems.
Simple loop operation Redis In fact Instead of benchmarking Redis, test your network (or IPC) latency. To truly test Redis, you need to use multiple connections (such as redis-benchmark), or use pipelining to aggregate multiple commands. You can also use Multi-threading or multi-process.
Redis is an in-memory database and provides some optional persistence features. If you want to compare with a persistence server (MySQL, PostgreSQL, etc.) If so, then you need to consider enabling AOF and an appropriate fsync strategy.
Redis is a single-threaded service. It is not designed to be optimized for multiple CPUs. If you want to get the benefits of multiple cores, Then consider enabling multiple instances. It's unfair to compare single-instance Redis with multi-threaded databases.
A common misunderstanding is that redis-benchmark deliberately makes the benchmark look better Well, the data presented seems artificial and not that of the real product.
The Redis-benchmark tool can quickly and easily calculate the performance parameters of the machine under specific hardware conditions. However, usually the following is the case This is not the maximum throughput that the Redis server can achieve. Using pipelining and faster clients (such as hiredis), higher throughput can be achieved. redis-benchmark by default only uses concurrency to improve throughput (create multiple connect). It doesn't use pipelining or other concurrency techniques, it just uses multiple connections instead of multi-threading.
If you want to use pipelining mode for benchmark testing (to achieve higher throughput), you can use the -P parameter. Many applications using Redis in production environments adopt this approach to improve performance.
Finally, the benchmark test needs to use the same operations and data for comparison. If these are not the same, then the benchmark test is meaningless.
For example, Redis and memcached can compare GET/SET operations in single-threaded mode. Both are in-memory databases, and the protocols are basically the same. Even the way of merging multiple requests into one request is similar (pipelining). This comparison is meaningful after using the same number of connections.
The following is a great example tested on Redis (antirez) and memcached (dormando).
antirez 1 - On Redis, Memcached, Speed, Benchmarks and The Toilet
dormando - Redis VS Memcached (slightly better bench)
antirez 2 - An update on the Memcached/Redis benchmark
You can find that the final result under the same conditions is not much different. Please note that at the time of final testing, both were fully optimized.
Finally, when a particularly high-performance server is benchmarked (such as Redis, memcached, etc.), it is difficult to fully utilize the server performance. Usually, the client is the bottleneck rather than the server. In this case, the client (such as the benchmark program itself) needs to be optimized or use multiple instances to achieve maximum throughput.
Factors affecting Redis performance
There are several factors that directly determine the performance of Redis. They can change the results of the benchmark, so we must pay attention to them. Normally, the default parameters of Redis are sufficient to provide efficient performance, so no tuning is required.
Network bandwidth and latency are usually the biggest shortcomings. I recommend using the ping command to detect latency between the server and client before benchmarking. Based on the bandwidth, the maximum throughput can be calculated. For example, if a 4 KB string is inserted into Redis and the throughput is 100,000 q/s, then 3.2 Gbits/s of bandwidth is actually required, so a 10 GBits/s network connection is required. 1 Gbits/s is not enough. In many online services, network bandwidth often becomes the limiting factor in Redis throughput sooner than CPU. In order to achieve high throughput and break through TCP/IP limitations, a 10 Gbits/s network card is finally used, or multiple 1 Gbits/s network cards.
CPU is another important influencing factor. Since it is a single-threaded model, Redis prefers a large cache and fast CPU rather than multiple cores. In this scenario, Intel CPU is more recommended. AMD CPUs are probably only half as powerful as Intel CPUs (compared to Nehalem EP/Westmere EP/Sandy platforms). If other conditions are equal, then the CPU is the bottleneck of redis-benchmark.
When accessing small objects, memory speed and bandwidth do not seem to be very important, but for large objects (> 10 KB), it becomes important. Generally speaking, people don't buy higher performance memory modules in order to optimize Redis.
Redis can be slow on a VM. Virtualization will have additional consumption on normal operations, while Redis will not have much overhead on system calls and network terminals. When latency is of particular concern, it is recommended to deploy Redis and run it on a physical server. On the most advanced virtualization device (VMware), the test results of redis-benchmark are twice as slow as those on the physical machine, and a lot of CPU time is consumed in system calls and interrupts.
If both the server and client are running on the same machine, both TCP/IP loopback and unix domain sockets can be used. For Linux, using unix sockets can be 50% faster than TCP/IP loopback. redis-benchmark uses the TCP/IP loopback interface by default.
The benefits of Unix domain sockets become less significant when extensive pipelining is used.
When using a network connection and the Ethernet data packet is less than 1500 bytes, packaging multiple commands into pipelining can greatly improve efficiency. In fact, when processing requests of 10 bytes, 100 bytes, and 1000 bytes, the throughput is almost the same. See the figure below for details.
The performance of Redis on multi-core CPU servers also depends on the NUMA configuration and processor binding position. The most significant impact of Redis-benchmark is that it randomly utilizes CPU cores. In order to obtain accurate results, you need to use fixed processor tools (on Linux, you can use taskset or numactl). The most effective way is to separate the client and server into two different CPUs to use third-level cache. Here are some benchmarks using 4 KB data SET, using different configurations for three CPUs (AMD Istanbul, Intel Nehalem EX, and Intel Westmere). Please note that this is not a CPU-specific test.
Under high configuration, the number of client connections is also an important factor. Redis's event loop benefits from epoll/kqueue and is therefore highly scalable. Redis has been benchmarked with more than 60,000 connections and can still maintain 50,000 q/s. A rule of thumb is that 30,000 connections only has half the throughput of 100 connections. Below is a test about the number of connections and throughput.
在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread。Jumbo frames 还可以在大对象使用时候获得更高性能。
在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。若非编译自行进行的 Redis，可用 INFO 命令验证内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的 Redis 实例来查看。
其他需要注意的点
任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。
一个好的实践是尽可能在隔离的硬件上面测试。需要检查基准测试是否受到其他服务器活动的影响，如果无法实现的话。
有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 CPU 分配策略。 这种策略可以在 OS 层面配置。有些 CPU 型号相对其他能更好的调整 CPU 负载。 为了达到可重现的测试结果，最好在做基准测试时候设定 CPU 到最高使用限制。
一个重要因素是配置尽可能大内存，千万不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的内存限制。
注意在执行基准测试时，如果使用了 RDB 或 AOF，请避免同时进行其他 I/O 操作。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。
将 Redis 日志级别设置到 warning 或者 notice。避免将日志放到远程文件系统。
避免使用检测工具，它们会影响基准测试结果。查看服务器状态可使用 INFO 命令，但使用 MONITOR 命令会严重影响测试准确性。
不同云主机和物理机器上的基准测试结果
这些测试模拟了 50 客户端和 200w 请求。
使用了 Redis 2.6.14。
使用了 loopback 网卡。
key 的范围是 100 w。
同时测试了 有 pipelining 和没有的情况（16 条命令使用 pipelining）。
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q SET: 552028.75 requests per second GET: 707463.75 requests per second LPUSH: 767459.75 requests per second LPOP: 770119.38 requests per second
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 122556.53 requests per second GET: 123601.76 requests per second LPUSH: 136752.14 requests per second LPOP: 132424.03 requests per second
Linode 2048 instance (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16 SET: 195503.42 requests per second GET: 250187.64 requests per second LPUSH: 230547.55 requests per second LPOP: 250815.16 requests per second
Linode 2048 instance (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 35001.75 requests per second GET: 37481.26 requests per second LPUSH: 36968.58 requests per second LPOP: 35186.49 requests per second
更多使用 pipeline 的测试
$ redis-benchmark -n 100000 ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <p>注意：包大小从 256 到 1024 或者 4096 bytes 不会改变结果的量级 （但是到 1024 bytes 后，GETs 操作会变慢）。同样的，50 到 256 客户端的测试结果相同。当使用10个客户端时，总吞吐量无法达到最大吞吐量。</p><p>不同机器可以获的不一样的结果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的结果：</p><pre class="brush:php;toolbar:false">$ ./redis-benchmark -q -n 100000 SET: 53684.38 requests per second GET: 45497.73 requests per second INCR: 39370.47 requests per second LPUSH: 34803.41 requests per second LPOP: 37367.20 requests per second
另外一个是 64 位 Xeon L5420 2.5 GHz 的结果：
$ ./redis-benchmark -q -n 100000 PING: 111731.84 requests per second SET: 108114.59 requests per second GET: 98717.67 requests per second INCR: 95241.91 requests per second LPUSH: 104712.05 requests per second LPOP: 93722.59 requests per second
高性能硬件下面的基准测试
Redis2.4.2 。
默认连接数，数据包大小 256 bytes。
Linux 是SLES10 SP3 2.6.16.60-0.54.5-smp，CPU 是 2 xIntel X5670 @ 2.93 GHz。
固定 CPU，但是使用不同 CPU 内核。
使用 unix domain socket：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256 PING (inline): 200803.22 requests per second PING: 200803.22 requests per second MSET (10 keys): 78064.01 requests per second SET: 198412.69 requests per second GET: 198019.80 requests per second INCR: 200400.80 requests per second LPUSH: 200000.00 requests per second LPOP: 198019.80 requests per second SADD: 203665.98 requests per second SPOP: 200803.22 requests per second LPUSH (again, in order to bench LRANGE): 200000.00 requests per second LRANGE (first 100 elements): 42123.00 requests per second LRANGE (first 300 elements): 15015.02 requests per second LRANGE (first 450 elements): 10159.50 requests per second LRANGE (first 600 elements): 7548.31 requests per second
使用 TCP loopback：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -d 256 PING (inline): 145137.88 requests per second PING: 144717.80 requests per second MSET (10 keys): 65487.89 requests per second SET: 142653.36 requests per second GET: 142450.14 requests per second INCR: 143061.52 requests per second LPUSH: 144092.22 requests per second LPOP: 142247.52 requests per second SADD: 144717.80 requests per second SPOP: 143678.17 requests per second LPUSH (again, in order to bench LRANGE): 143061.52 requests per second LRANGE (first 100 elements): 29577.05 requests per second LRANGE (first 300 elements): 10431.88 requests per second LRANGE (first 450 elements): 7010.66 requests per second LRANGE (first 600 elements): 5296.61 requests per second
The above is the detailed content of How to check Redis benchmark parameters. For more information, please follow other related articles on the PHP Chinese website!