Body

Redis comes with a redis-benchmark tool to simulate N clients sending M requests at the same time. You can use redis-benchmark -h to view the benchmark parameters.

Syntax

The basic commands for Redis performance testing are as follows:

redis-benchmark [option] [option value]

The optional parameters of the Redis performance test tool are as follows:

Test

After deploying the Redis container locally, test it.How to deploy a Redis container has been discussed for the first time!So don't repeat it!

Performance testing

The test results are numerous.So only SET and GET methods were chosen

Explanation: 10 concurrent numbers, 100 requests, completed within 0.02 seconds, 3 bytes are sent each time, and only 1 Redis server node is connected.

It can be seen from the above that 100 SET requests are completed within 0.02 seconds, and the final requests are completed within 4 seconds, which can handle 5263.16 requests per second.

100 GET requests are completed in 0.0 seconds, and the last request is completed in 0 seconds, which can handle 33333.33 requests per second.

Condensed Quick Test

Syntax: redis-benchmark -h localhost -p 6379 -a dangerous -c 10 -n 100 -q

Factors affecting Redis performance

There are several factors that directly determine the performance of Redis.They can change the benchmark results, so we have to pay attention to them.In general, the default parameters of Redis can already provide sufficient performance and do not require tuning.

• Network bandwidth and latency are often the biggest weaknesses.It is recommended to use ping to check server-to-client latency before benchmarking.Based on the bandwidth, the maximum throughput can be calculated.For example, when a 4 KB string is inserted into Redis, the throughput is 100000 q/s, then the actual bandwidth is 3.2 Gbits/s, so 10 GBits/s network connection is required, and 1 Gbits/s is not enough.In many online services, Redis throughput is limited by network bandwidth, not CPU.In order to achieve high throughput beyond the limits of TCP/IP, a 10 Gbits/s network card, or multiple 1 Gbits/s network cards, is finally used.
• CPU is another important factor. Due to the single-threaded model, Redis prefers fast CPUs with large caches instead of multi-core.In this scenario, Intel CPU is recommended.AMD CPUs may have half the performance of Intel CPUs (by comparing Nehalem EP/Westmere EP/Sandy platforms).When other things are equal, the CPU becomes the limiting factor for redis-benchmark.
• Memory speed and bandwidth do not seem to be very important when accessing small objects, but for large objects (> 10 KB) it becomes important.However, under normal circumstances, it is not necessary to buy higher-performance memory modules in order to optimize Redis.
• Redis can be slow on VMs.Virtualization will have additional consumption for ordinary operations, and Redis will not have too much overhead for system calls and network terminals.It is recommended to run Redis on a physical machine, especially if you are concerned about latency.On state-of-the-art virtualized devices (VMWare), redis-benchmark results are twice as slow as on physical machines, and a lot of CPU time is spent on system calls and interrupts.
• If both 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.The default redis-benchmark is to use TCP/IP loopback.The advantages of unix domain sockets are less obvious when pipelining is used heavily.
• The advantage of unix domain sockets is less obvious when pipelining is used heavily.
• When using a network connection and the Ethernet network packet is under 1500 bytes, wrapping multiple commands into pipelining can greatly improve efficiency.In fact, when processing requests of 10 bytes, 100 bytes, and 1000 bytes, the throughput is similar,

Other points to note

• An important goal of any benchmark is to obtain reproducible results so that this can be compared to other tests.

• A good practice is to test on isolated hardware whenever possible.If this is not possible, then it is necessary to check that the benchmark is not affected by other server activity.
• Some configurations (desktops and laptops, and some servers too) use variable CPU allocation strategies.This policy can be configured at the OS level.Some CPU models adjust CPU load better than others.In order to achieve reproducible test results, it is best to set the CPU to the maximum usage limit when doing benchmarks.
• An important factor is to configure as much memory as possible and never use SWAP.Note that 32-bit and 64-bit Redis have different memory limits.
• If you plan to use RDB or AOF for benchmarking, be careful not to have other I/Os on the system at the same time.Avoid placing RDB or AOF files on NAS or NFS shares or other network-dependent storage devices (such as EBS on Amazon EC2).
• Set the Redis log level to warning or notice.Avoid putting logs on remote filesystems.
• Avoid detection tools, which can affect benchmark results.Using INFO to view server status is fine, but using MONITOR will greatly affect test accuracy.

Reference: REDIS benchmarks-- Redis Chinese Data Station -- Redis Chinese User Group (CRUG)