Several test results for Redis

Scenario One: A single key large concurrency increase (INC) operation to simulate inventory modifications to hotspot products

Test point:
Atomicity, guaranteeing that the last key value equals the sum performance of all the key values added to the operation,
Ensure that the performance of write operations is not greatly reduced under large concurrency

Number of threads	Average time for 100 Inc operations	Service-side data
10	140	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 342 instantaneous_input_kbps (Bytes read/sec): 10.70 instantaneous_output_kbps (number of writes per second): 1.90 Used_cpu_sys (System CPU Usage): 0.05 Used_cpu_user (User CPU usage): 0.03
50	560	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2780 instantaneous_input_kbps (Bytes read/sec): 86.89 instantaneous_output_kbps (number of writes per second): 18.20 Used_cpu_sys (System CPU Usage): 0.48 Used_cpu_user (User CPU usage): 0.37
100	1050	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 5766 instantaneous_input_kbps (Bytes read/sec): 180.22 instantaneous_output_kbps (number of writes per second): 38.60 Used_cpu_sys (System CPU Usage): 1.31 Used_cpu_user (User CPU usage): 0.52
120	1400	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 6857 instantaneous_input_kbps (Bytes read/sec): 214.29 instantaneous_output_kbps (number of writes per second): 46.87 Used_cpu_sys (System CPU Usage): 2.51 Used_cpu_user (User CPU usage): 0.81
150	1570	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 8350 instantaneous_input_kbps (Bytes read/sec): 260.95 instantaneous_output_kbps (number of writes per second): 58.74 Used_cpu_sys (System CPU Usage): 4.04 Used_cpu_user (User CPU usage): 1.13

Conclusion:
The client 100 times the time increases with the number of threads, but the service side of the processing volume does not reach the limit, CPU usage is not high, it can be seen that redis processing high concurrent requests no problem.
JVISUALVM Analysis Results: Client processing time is mainly due to the cost of thread switching and network overhead

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6F/22/wKiom1WSWHbAE0EGAAMuCeJojHo135.jpg "title=" Visualvmres.png "alt=" Wkiom1wswhbae0egaamucejojho135.jpg "/>

Scenario Two: Data persistence test

Data consumption memory Size:
400,000 data, key length 20, data length 1. Takes up to 28.90M total
2 million data, key length 20, data length 1. Takes up to 138.55M total

Persistence mode	Data volume	Client time	Service-side data
RDB mode, data snapshots are written to disk periodically Rule: Write to disk every 900 seconds if the data changes more than 1 times Write to disk every 300 seconds if the data changes more than 10 times Write to disk every 60 seconds if the data changes more than 10,000 times	Write 400,000 times	148397 ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2538 instantaneous_input_kbps (Bytes read/sec): 116.52 instantaneous_output_kbps (number of writes per second): 12.40 latest_fork_usec:614
	Write 2 million times	750721ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2705 instantaneous_input_kbps (Bytes read/sec): 126.80 instantaneous_output_kbps (number of writes per second): 13.21 latest_fork_usec:889
Data not persisted	Write 400,000 times	145062 ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2840 instantaneous_input_kbps (Bytes read/sec): 130.38 instantaneous_output_kbps (number of writes per second): 13.87
	Write 2 million times	746384ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2723 instantaneous_input_kbps (Bytes read/sec): 127.68 instantaneous_output_kbps (number of writes per second): 13.30
Data is copied to a single node	Write 400,000 times	210540ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2222 instantaneous_input_kbps (Bytes read/sec): 102.00 instantaneous_output_kbps (number of writes per second): 112.83
	Write 2 million times	9249390ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2126 instantaneous_input_kbps (Bytes read/sec): 99.69 instantaneous_output_kbps (number of writes per second): 110.05
AOF mode FYSNC per second Operations are written to disk in logs, and logs are brushed from the disk buffer into the hard disk every second	Write 400,000 times	158809ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2169 instantaneous_input_kbps (Bytes read/sec): 99.59 instantaneous_output_kbps (number of writes per second): 10.59
	Write 2 million times	765037ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2656 instantaneous_input_kbps (Bytes read/sec): 124.54 instantaneous_output_kbps (number of writes per second): 12.97
AOF mode: Fsync always Operations are written to disk in log mode, each time the log is flushed from disk into the hard disk	Write 400,000 times	583053ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 642 instantaneous_input_kbps (Bytes read/sec): 29.49 instantaneous_output_kbps (number of writes per second): 3.14
	Write 2 million times	3154548ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 613 instantaneous_input_kbps (Bytes read/sec): 28.77 instantaneous_output_kbps (number of writes per second): 2.99
AOF mode: Fsync never Operations are written to disk in log mode, and the operating system determines when the logs are flushed from disk to the hard disk	Write 400,000 times	152612ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2725 instantaneous_input_kbps (Bytes read/sec): 125.07 instantaneous_output_kbps (number of writes per second): 13.30
	Write 2 million times	769203ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 2710 instantaneous_input_kbps (Bytes read/sec): 127.03 instantaneous_output_kbps (number of writes per second): 13.23
RDB mode, data snapshots are written to disk periodically Rule: Write to disk every 900 seconds if the data changes more than 1 times Write to disk every 300 seconds if the data changes more than 10 times Write to disk every 60 seconds if the data changes more than 10,000 times Use pipeline batch operations, every 10,000 commits	Write 400,000 times	1429ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 131611 instantaneous_input_kbps (Bytes read/sec): 6040.77 instantaneous_output_kbps (number of writes per second): 641.57
	Write 2 million times	6740ms	INSTANTANEOUS_OPS_PER_SEC (number of processing instructions per second): 161782 instantaneous_input_kbps (Bytes read/sec): 7583.55 instantaneous_output_kbps (number of writes per second): 791.00

Conclusion:

• The RDB and non-persistent performance differences are not significant, mainly because the RDB replicates the data by fork and has no effect on the read and write of the main process. But the cost of a single fork is large, and it consumes twice times more memory when fork

• AoF mode per second Fsync and operating system Fsync difference is not big, but always fsync performance drops sharply, Fsync per second is a more appropriate choice, the maximum loss of 1 seconds of data, performance is good

• Large amounts of data do not have much impact on the performance of write operations

• The performance of the log master-slave replication is not small, but because it is a single-machine simulation cluster test, the hardware and network are shared, the data may not be allowed, it is recommended to re-test in the actual environment

• 4 million data read performance is still 5 to 7 milliseconds/bar

• Data recovery: 4 million data, Rdb mode initialization takes approximately 4.12 seconds (can be found from Redis.log), AoF mode initialization takes about 6.216 seconds

• Pipeline batch processing mode is a great boost for write performance, but with limited usage scenarios, it can typically be used for initial redis data

Several test results for Redis