Performance testing: redis performance testing of tens of millions of data volumes

Performance testing of tens of millions of redis data volumes
We can guess that there will also be a redis 2.2.1 test, the same test environment, 1 K data volume, using servicestack. the redis client performs the following test: 1) set operation 2) Get operation 3) del operation each test uses three configurations for test: 1) the green line enables dump persistence, and persists once every 5 minutes. 2)

We can guess that there will also be a redis 2.2.1 test, the same test environment, 1 K data volume, use the servicestack. redis client to perform the following test:
1) set operation
2) Get operation
3) del operation
Each set of tests uses three configurations for testing:
1) the green line is to enable the dump mode for persistence, once every 5 minutes
2) The blue lines enable aof persistence and write data to the disk once per second.
3) red lines are used to close any persistence mode.
Use the same configurations for each Configuration:
1) switch out after enabling the maximum VM memory of 10 GB (one page of 128 bytes). The VM space is 160 GB.
2) The maximum memory usage is 15 GB. Make sure there is enough memory available during dump.
3) Enable compression without configuring Master/Slave
Now let's take a look at the test results:

From this figure, we can see that:
1) for the non-persistent mode, when the data volume of read and write operations reaches 8 million, the performance will be several times lower, and the memory will reach 10 Gb at this time, and redis will begin to switch out to the disk. Since then, there has been no way to refresh again, and the performance is much worse than that of MongoDB.
2) For the aof persistence method, the overall performance will not be much worse than the non-persistence method. The total data volume is tens of millions, and the read performance is only several hundred after the memory is full.
3) for the dump persistence mode, the read/write performance fluctuates greatly, and may be related to the dump during that time. After the data volume reaches 14 million, the read/write performance is reduced. During dump, it will not be swapped out, and all the modified data is still the new page created. The memory usage is much higher than usual and exceeds 15 GB. In addition, dump also compresses and occupies a large amount of CPU. That is to say, at that time, the pressure on the memory, disk, and CPU was close to the limit, and performance was not bad.
Summary:
1) redis is only suitable for caching, not for databases or storage. Its persistence method is suitable for saving and cannot be used as a common function. We do not recommend any persistence mode for this version of redis. Otherwise, it may become ugly. To put it bluntly, we expect redis to be an upgraded version of memcached with a variety of data structures, but do not expect redis to be compared with MongoDB/KT.
2) It is not recommended to enable the VM. Although enabling the VM allows redis to save more data than the memory, however, if the cold and hot data is not obvious, the performance will be very poor (my tests all query keys randomly, and the cold and hot data are not obvious ). Of course, you can set 200%-400% of the memory as the VM space when the hot and cold data is obvious, or you are not recommended to set 10 times of memory space as the VM (like my configuration ).
3) servicestack. the redis client seems to have several bugs. First, the dispose of the redistypedclient is not implemented. It should be called by the client. dispose (). Second, the info attribute of redisnativeclient does not get the latest value every time. The writepoolindex and readpoolindex values of pooledredisclientmanager only see the vertices not added or subtracted, in fact, you can obtain the first client that is not active each time. pooledredisclientmanager does not forcibly recycle the active client that is used for timeout (avoid forgetting to use dispose to occupy too many connections ). I will try to contact the author of servicestack. redis.