-
Type:
Question
-
Resolution: Incomplete
-
Priority:
Major - P3
-
None
-
Affects Version/s: 4.2.3, 4.0.16
-
Component/s: None
-
Labels:None
-
Fully Compatible
Running YCSB it was possible to identify a performance regression around 18% for MongoDB 4.0 and 4.2 for read operations compared to 3.6.
The test used:
./bin/ycsb load mongodb -s -P workloads/workloada -p recordcount=5000000 -p mongodb.url="mongodb://admin:admin@localhost:27017/ycsb?authSource=admin&w=0" -p mongodb.auth="true" -threads 10
./bin/ycsb run mongodb -s -P workloads/workloadc -p operationcount=5000000 -p mongodb.url="mongodb://admin:admin@localhost:27017/ycsb?authSource=admin&w=0&compressors=zlib" -p mongodb.auth="true" -threads 30
$cat ./workloads/workloadc
recordcount=1000
operationcount=1000
workload=site.ycsb.workloads.CoreWorkload
readallfields=true
readproportion=0.8
updateproportion=0.15
scanproportion=0
insertproportion=0.5
The tests were run on t2.xlarge machines on AWS where the conditions below were met:
3 - mongoD
1- config server
1- mongoS + YCSB
The dataset fits in memory and there was no resource contention.
Using perf(attached the flame graph) it seems that transaction features are the culprit.
