Redis performance test

Prepare the environment:

Because no 1000 m network machine is available, connect the two laptops with a direct connection to form a M Ethernet network. Yes, it's a straight-through line. Now, the network card can adapt to cross-line and direct-through lines, and the speed is not affected. After a while, the machine has no problem.

Server: t420 i5-2520M (2.5G)/8g Ubuntu 11.10

Client: Acer i5-2430M (2.4g)/4G mint 11

Redis version: 2.6.9

Test script:./Redis-benchmark-h xx-p xx-t set-Q-r 1000-l-D 20

Length	Speed/sec	Bandwidth (MByte/s) Sending + receiving	CPU	CPU detail
20 bytes	17 W	24 m + 12 m	98.00%	Cpu0: 21.0% us, 40.7% Sy, 0.0% Ni, 4.3% ID, 0.0% wa, 0.0% hi, 34.0% Si, 0.0% St
100 bytes	17 W	37 m + 12 m	97.00%	Cpu0: 20.3% us, 37.9% Sy, 0.0% Ni, 7.0% ID, 0.0% wa, 0.0% hi, 34.9% Si, 0.0% St
512 bytes	12 W	76 m + 9 m	87.00%	Cpu0: 20.9% us, 33.2% Sy, 0.0% Ni, 25.6% ID, 0.0% wa, 0.0% hi, 20.3% Si, 0.0% St
1 K	9 W	94 m + 8 m	81.00%	Cpu0: 19.9% us, 30.2% Sy, 0.0% Ni, 34.2% ID, 0.0% wa, 0.0% hi, 15.6% Si, 0.0% St
2 K	5 W	105 m + 6 m	77.00%	Cpu0: 18.0% us, 32.0% Sy, 0.0% Ni, 34.7% ID, 0.0% wa, 0.0% hi, 15.3% Si, 0.0% St
5 K	2.2 million	119 M + 3.2 m	77.00%	Cpu0: 22.5% us, 32.8% Sy, 0.0% Ni, 32.8% ID, 0.0% wa, 0.0% hi, 11.9% Si, 0.0% St
10 K	1.1 million	119 M + 1.7 m	70.00%	Cpu0: 18.2% us, 29.8% Sy, 0.0% Ni, 42.7% ID, 0.0% wa, 0.0% hi, 9.3% Si, 0.0% St
20 K	0.57 million	120 m + 1 m	58.00%	Cpu0: 17.8% us, 26.4% Sy, 0.0% Ni, 46.2% ID, 0.0% wa, 0.0% hi, 9.6% Si, 0.0% St

When the value is 1 K or more, the M Nic is easily slow, and the redis-server CPU is not occupied by a core. It can be seen that redis is efficient and redis services do not require too high configuration, the bottleneck lies in the speed of the NIC.

Check that redis's us is around 20% at the user layer.CodeResource usage is very small.

Value may seem a waste of time if it is very small, so open a few more redis-server to see, value: 20 byte:

When there are two redis instances:

Length	Speed/sec	Bandwidth (MByte/s) Sending + receiving	CPU	CPU detail
20 bytes	10 W + 10 W	26 m + 14 m	98% + 98%	Cpu0: 18.9% us, 20.5% Sy, 0.0% Ni, 0.3% ID, 0.0% wa, 0.0% hi, 60.3% Si, 0.0% St Cpu1: 41.2% us, 56.5% Sy, 0.0% Ni, 2.3% ID, 0.0% wa, 0.0% hi, 0.0% Si, 0.0% St

When there are three redis instances:

 

Length	Speed/sec	Bandwidth (MByte/s) Sending + receiving	CPU	CPU detail
20 bytes	7 W * 3	26 m + 14 m	67% * 3	Cpu0: 20.6% us, 19.9% Sy, 0.0% Ni, 0.7% ID, 0.0% wa, 0.0% hi, 58.8% Si, 0.0% St Cpu1: 37.9% us, 54.2% Sy, 0.0% Ni, 8.0% ID, 0.0% wa, 0.0% hi, 0.0% Si, 0.0% St Cpu2: 5.7% us, 4.7% Sy, 0.0% Ni, 88.0% ID, 1.7% wa, 0.0% hi, 0.0% Si, 0.0% St Cpu3: 5.6% us, 2.6% Sy, 0.0% Ni, 91.7% ID, 0.0% wa, 0.0% hi, 0.0% Si, 0.0% St

 

Nic interruption processing is the bottleneck when packets are sent, and nic speed is the bottleneck when packets are sent. Therefore, in addition to the wireless program security considerations, single-thread processing of redis is a thread with no pressure and no need for handling.

For small values, you can use pipleline to enable Nagle in TCP.AlgorithmTo improve the processing capability.

It seems that all three instances are running at the same core, and cpu0 cpu1 is the same physical core hyper-threading. The Soft Interrupt occupies 60%, and the Soft Interrupt becomes a bottleneck in the fixed CPU. The next time the Soft Interrupt is distributed to another CPU, the test will show the effect.