網易視頻雲:HBase BlockCache系列-性能對比測試報告

      網易視頻雲是網易傾力打造的一款基於雲計算的分佈式多媒體處理集羣和專業音視頻技術,提供穩定流暢、低時延、高併發的視頻直播、錄製、存儲、轉碼及點播等音視頻的PAAS服務,在線教育、遠程醫療、娛樂秀場、在線金融等各行業及企業用戶只需經過簡單的開發即可打造在線音視頻平臺。

  HBase BlockCache系列文章到了終結篇,幾個主角的是是非非也該有個了斷了,在SlabCache被早早地淘汰之後,站在華山之巔的也就僅剩LRU君(LRUBlockCache)和CBC君(CombinedBlockCache)。誰贏誰輸,我說了不算,你說了也不算,那就來讓數據說話。這篇文章主要對比LRU君和CBC君(offheap模式)分別在四種場景下幾種指標(GC、Throughput、Latency、CPU、IO等)的表現情況。四種場景分別是緩存全部命中、少大部分緩存命中、少量緩存命中、緩存基本未命中。

  需要注意的是,本文的所有數據都來自社區文檔,在這裏分享也只是給大家一個參考,更加詳細的測試數據可以閱讀文章《Comparing BlockCache Deploys》和 HBASE-11323附件報告。

  說明:本文所有圖都以時間爲橫座標,縱座標爲對應指標。每張圖都會分別顯示LRU君和CBC君的四種場景數據,總計八種場景,下面數據表示LRU君的四種場景分佈在時間段21:36:39~22:36:40,CBC君的四種場景分佈在時間段23:02:16~00:02:17,看圖的時候需要特別注意。

  LRU君:Tue Jul 22 21:36:39 PDT 2014 run size=32, clients=25 ; lrubc time=1200 緩存全部命中Tue Jul 22 21:56:39 PDT 2014 run size=72, clients=25 ; lrubc time=1200 大量緩存命中Tue Jul 22 22:16:40 PDT 2014 run size=144, clients=25 ; lrubc time=1200 少量緩存命中Tue Jul 22 22:36:40 PDT 2014 run size=1000, clients=25 ; lrubc time=1200 緩存基本未命中

  CBC君:Tue Jul 22 23:02:16 PDT 2014 run size=32, clients=25 ; bucket time=1200 緩存全部命中Tue Jul 22 23:22:16 PDT 2014 run size=72, clients=25 ; bucket time=1200 大量緩存命中Tue Jul 22 23:42:17 PDT 2014 run size=144, clients=25 ; bucket time=1200 少量緩存命中Wed Jul 23 00:02:17 PDT 2014 run size=1000, clients=25 ; bucket time=1200 緩存基本未命中

  GC

  GC指標是HBase運維最關心的指標,出現一次長時間的GC就會導致這段時間內業務方的所有讀寫請求失敗,如果業務方沒有很好的容錯,就會出現丟數據的情況出現。根據下圖可知,只有在‘緩存全部命中’的場景下,LRU君總GC時間25ms比CBC君的75ms短;其他三種場景下,LRU君表現都沒有CBC君好,總GC時間基本均是CBC君的3倍左右。

  

  Thoughput

  吞吐量可能是所有HBase用戶初次使用最關心的問題,這基本反映了HBase的讀寫性能。下圖是隨機讀測試的吞吐量曲線,在‘緩存全部命中’以及‘大量緩存命中’這兩種場景下,LRU君可謂是完勝CBC君,特別是在‘緩存全部命中’的場景下,LRU君的吞吐量甚至是CBC君的兩倍;而在‘少量緩存命中’以及‘緩存基本未命中’這兩種場景下,兩者的表現基本相當;

  

  Latency

  讀寫延遲是另一個用戶很關心的指標,下圖表示在所有四種情況下LRU君和CBC君都在伯仲之間,LRU君略勝一籌。

  

  IO

  接下來兩張圖是資源使用圖,運維同學可能會比較關心。從IO使用情況來看,兩者在四種場景下也基本相同。

  

  CPU

  再來看看CPU使用情況,在‘緩存全部命中’以及‘大量緩存命中’這兩種場景下,LRU君依然完勝CBC君,特別是在‘緩存全部命中’的場景下,CBC君差不多做了兩倍於LRU君的工作;而在‘少量緩存命中’以及‘緩存基本未命中’這兩種場景下,兩者的表現基本相當;

  

  結論

  看完了所有比較重要的指標對比數據,我們可以得出以下兩點:

  1. 在’緩存全部命中’場景下,LRU君可謂完勝CBC君。因此如果總數據量相比JVM內存容量很小的時候,選擇LRU君;

  2. 在所有其他存在緩存未命中情況的場景下, LRU君的GC性能幾乎只有CBC君的1/3,而吞吐量、讀寫延遲、IO、CPU等指標兩者基本相當,因此建議選擇CBC。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章