mongodb 3.2效能測試

標籤：rpe   價值   god   delay   ons   enc   read   nbsp   poi   

測試環境機器配置

linux container 

• 4C/16G/300GSSD
• 8C/32G/300GSSD

測試對象

版本	引擎	參數配置
		4C/16G	8C/32G
mongodb3.2.6	wiredTiger	cacheSizeGB:12 syncPeriodSecs: 1 collectionConfig: blockCompressor: snappy indexConfig: prefixCompression: true	cacheSizeGB:24 syncPeriodSecs: 1 collectionConfig: blockCompressor: snappy indexConfig: prefixCompression: true
tokumx1.5	tokumx	cacheSize=12G syncdelay=5	cacheSize=24G syncdelay=5
tokumx2.0.2	tokumx	cacheSize=12G checkpointPeriod=10 cleanerIterations=10 directio=false cleanerPeriod=2 syncdelay=5	cacheSize=24G checkpointPeriod=10 cleanerIterations=10 directio=false cleanerPeriod=2 syncdelay=5

 測試情境

• 測試單節點環境

1. 100%insert
2. 單節點_50%update50%read
3. 5%update5%insert90%read
4. 100%read
5. wiredtiger_syncPeriodSecs_60與1比較
6. sharding叢集效能壓測

• 說明

1. 情境1-4每次載入1000W資料，資料大小約13G
2. 情境5載入5000W資料，資料大小約75G

測試方法

• YCSB壓測

測試結果情境1：單節點_100%insert (load data)情境2：單節點_50%update50%read

 

情境3：單節點_5%update5%insert90%read 情境4：單節點_100%read 情境5：wiredtiger_syncPeriodSecs_60_1

 

 

 情境6：sharding叢集效能測試

 

 

結論

• load效能比較，wiredtiger優勢十分明顯，速度大約是同配置tokumx的5倍，且RT較短
• 唯讀效能，wiredTiger效能和tokumx,比較，效能較差，但穩定；
• 複雜情況下，wiredTiger效能較好，可支撐更高並發度的線程調用；
• 如果不基於磁碟和網路輸送量考慮，三個以下節點的 sharding 從效能上沒有價值，現階段結果看來，儘可能多的部署 mongos，能有效提升總體的叢集利用率。

   

mongodb 3.2效能測試