Redis千万级的数据量的性能测试

从图中能够猜想到还会有Redis 2.2.1 的测试，相同的测试环境，1K的数据量，使用ServiceStack.Redis客户端进行以下测试： 1) Set操做 2) Get操做 3) Del操做 每一套测试分别使用三个配置进行测试： 1) 绿色线条的是开启Dump方式的持久化，5分钟持久化一次 2)

   

     

 　　从图中能够猜想到还会有Redis 2.2.1  的测试，相同的测试环境，1K的数据量，使用ServiceStack.Redis客户端进行以下测试：

　　1) Set操做

　　2) Get操做

　　3) Del操做

　　每一套测试分别使用三个配置进行测试：

　　1) 绿色线条的是开启Dump方式的持久化，5分钟持久化一次

　　2) 蓝色线条是开启AOF方式的持久化，每秒写入磁盘一次

　　3) 红色线条是关闭任何的持久化方式

　　对于每个配置都使用相同的其余配置：

　　1) 开启VM 最大内存10GB(128字节一页)以后开始换出，VM空间160GB

　　2) 最大使用内存15GB，确保在Dump的时候有足够的剩余内存

　　3) 开启压缩，没有配置主从

　　如今来看一下测试结果：

　　

 

　　从这个图中能够看出：

　　1)  对于没有持久化的方式，读写都在数据量达到800万的时候，性能降低几倍，此时正好是达到内存10G，Redis开始换出到磁盘的时候。而且从那之后再也没办法从新振做起来，性能比Mongodb还要差不少。

　　2) 对于AOF持久化的方式，整体性能并不会比不带持久化方式差太多，都是在到了千万数据量，内存占满以后读的性能只有几百。

　　3)   对于Dump持久化方式，读写性能波动都比较大，可能在那段时候正在Dump也有关系，而且在达到了1400万数据量以后，读写性能贴底了。在Dump的 时候，不会进行换出，并且全部修改的数据仍是建立的新页，内存占用比平时高很多，超过了15GB。并且Dump还会压缩，占用了大量的CPU。也就是说， 在那个时候内存、磁盘和CPU的压力都接近极限，性能不差才怪。

　　总结一下：

　　1)   Redis其实只适合做为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合看成一个普通功能来用。对于这个版本的Redis，不建 议使用任何的持久化方式。不然到时候可能会死的比较难看。说白了，指望Redis是memcached的升级版，带有各类数据结构，可是不要指望 Redis来和Mongodb/Kt等来比。

　　2)   对于VM其实也是不建议开启，虽然开启VM可让Redis保存比内存更多的数据，可是若是冷热数据不是很明显的话性能会很是差(个人测试都是随机查询 Key，冷热不明显)。固然，对于冷热明显的状况下能够设置200%  - 400%的内存做为VM空间，也不建议设置10倍的内存空间做为VM(像个人配置同样)。

　　3)   ServiceStack.Redis客户端好像有几个Bug，首先RedisTypedClient的Dispose竟然没有实现，应该是要调用 client.Dispose()，其次RedisNativeClient的Info属性不是每次都获取最新值的，第三 PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加没看到减的地方，也不知道这是干 啥的，其实每次都取第一个不是Active的Client就能够了，PooledRedisClientManager也没有把超时使用的Active的 Client强制回收(避免使用的时候忘记Dispose占用过多的链接)。有关这几点，我会尝试联系ServiceStack.Redis的做者。