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的做者。