mongodb 3.2性能測試
阿新 • • 發佈：2017-09-01
borde 性能測試 enc 引擎 linux cpe rect png index
測試環境
機器配置
linux container
- 4C/16G/300GSSD
- 8C/32G/300GSSD
測試對象
| 版本 | 引擎 | 參數配置 | |
|---|---|---|---|
|
4C/16G |
8C/32G | ||
| mongodb3.2.6 | wiredTiger |
|
|
| 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 |
測試場景
- 測試單節點環境
- 100%insert
- 單節點_50%update50%read
- 5%update5%insert90%read
- 100%read
- wiredtiger_syncPeriodSecs_60與1比較
- sharding集群性能壓測
- 說明
- 場景1-4每次加載1000W數據，數據大小約13G
- 場景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性能測試