How fast is Redis? Why is Redis fast?

How fast is Redis?

Redis uses a memory-based KV database with a single-process single-thread model, written in C. The official data provided is a QPS (queries per second) that can reach 100,000+. This data is not worse than the same memory-based KV database Memcached with single-process multi-threading!

Why is it so fast?

1. Based entirely on memory , most requests are pure memory operations, very fast. Data stored in memory;

2. The data structure is simple , and the data operation is also simple. The data structure in Redis is specially designed;

3. Single thread is used to avoid unnecessary context switching and race conditions. There is no multi-process or multi-threaded switching that consumes CPU. There is no need to consider various locks. There is no lock release operation. Performance consumption due to possible deadlocks;

4. Use multiple I / O multiplexing model, non-blocking IO ; "Multiple" here refers to multiple network connections, and "multiplexing" refers to multiplexing the same thread. The use of multiple I / O multiplexing technology allows a single thread to efficiently process multiple connection requests (minimizing the time consumption of network IO), and Redis operates data in memory very quickly, meaning that operations in memory are It will become a bottleneck that affects the performance of Redis, mainly because of the above points, Redis has a high throughput.

5. The underlying model is different . The underlying implementation method and the communication protocol between the client and the client are different. Redis directly builds the VM mechanism by itself. Because the general system calls system functions, it will waste some time to move And request;

The above points are relatively easy to understand. Let's briefly discuss the multi-channel I / O reuse model :

Since Redis is single-threaded, if it is traditional blocking IO, then each IO operation will be performed sequentially. If the current IO is unreadable or writable, the entire Redis will become blocked without asking whether Other IO streams are readable and writable.

Redis is I / O multiplexed and uses select, poll, and epoll methods. The first two are thread-unsafe. The official documentation for select says:

A Sock (I / O Stream) is inserted into the select. If another thread finds that the current sock is unavailable, the sock must be retracted. Select is not supported. You hard turned off this sock, and there may be multiple results for the operation of this stream in the end. "If a file descriptor being monitored by select () is closed in another thread, the result is unspecified"



epoll is:
(1) thread-safe,
(2) Not only will the sock be notified of the data, it will also be specifically informed of the data in the sock. The selection only tells you that there is data in the sock, and does not return the specific sock. You need to find it one by one. If there are tens of thousands of socks, it is quite laborious to find them.
(3) Only support Linux platform

Redis performance

Several factors directly determine the performance of Redis. They can change the results of benchmarks, so we must pay attention to them. In general, the default parameters of Redis can already provide sufficient performance without tuning.

Network bandwidth and latency are usually the biggest shortcomings. It is recommended to use ping to check server-to-client latency before benchmarking. From the bandwidth, the maximum throughput can be calculated. For example, stuffing a 4 KB string into Redis, and the throughput is 100,000 q / s, then the actual bandwidth of 3.2 Gbits / s is needed, so a 10 GBits / s network connection is needed, and 1 Gbits / s is not enough. In many online services, Redis throughput is first limited by network bandwidth, not CPU. In order to achieve high throughput and break through the TCP / IP limitation, a 10 Gbits / s network card or multiple 1 Gbits / s network cards is finally adopted.
The CPU is another important factor. Because it is a single-threaded model, Redis prefers large caches and fast CPUs rather than multi-cores. In this scenario, Intel CPU is recommended. AMD CPUs may only have half the performance of Intel CPUs (compared to Nehalem EP / Westmere EP / Sandy platforms). When other conditions are equal, the CPU becomes the limiting factor of redis-benchmark.
When accessing small objects, memory speed and bandwidth don't seem to be important, 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 is slower on the VM. Virtualization will have additional consumption for normal 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 delays. 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 by system calls and interrupts.
If the server and client are running on the same machine, then 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. When pipelining is used heavily, the advantages of unix domain sockets are less obvious.
When pipelining is used heavily, the advantages of unix domain sockets are less obvious.
When using a network connection and the Ethernet network data packet is below 1500 bytes, wrapping multiple commands into pipelining can greatly improve efficiency. In fact, when processing requests of 10 bytes, 100 bytes, 1000 bytes, the throughput is similar, as shown in the figure below.

On multi-core CPU servers, the performance of Redis also depends on the NUMA configuration and processor binding location. The most noticeable effect is that redis-benchmark uses CPU cores randomly. In order to get accurate results, you need to use a fixed processor tool (you can use taskset or numactl on Linux). The most effective way is to separate the client and server to two different CPUs to use the L3 cache in colleges. Here are some benchmark tests 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 test for the CPU.

In high configurations, the number of client connections is also an important factor. Thanks to epoll / kqueue, Redis's event loop is quite scalable. Redis has been benchmarked under more than 60,000 connections and still maintains 50,000 q / s. A rule of thumb is that 30,000 connections are only half the throughput of 100 connections. Below is a test on the number of connections and throughput.

In high configurations, you can tune the NIC for higher performance. The highest performance can be achieved only by binding the Rx / Tx queue and the CPU core, and RPS (Network Card Interrupt Load Balancing) needs to be enabled. More information can be found in  thread  . Jumbo frames can also achieve higher performance when used with large objects.

Under different platforms, Redis can be compiled into different memory allocation methods (libc malloc, jemalloc, tcmalloc), and they will behave differently under different speeds, continuous and non-contiguous fragments. If you are not compiling Redis yourself, you can use the INFO command to check the memory allocation method. Please note that most benchmarks do not run for a long time to perceive the differences under different allocation modes, and can only be viewed through Redis instances under the production environment.