Redis千萬級的資料量的效能測試

從上篇的圖中可以猜測到還會有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的作者。