[SERVER-60718] Access of sub-fields is slow in SBE queries Created: 14/Oct/21  Updated: 27/Oct/23  Resolved: 26/Sep/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Irina Yatsenko (Inactive) Assignee: Mihai Andrei
Resolution: Gone away Votes: 0
Labels: pm2697-m3, sbe
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File sbe-point-subfield.svg    
Issue Links:
Depends
is depended on by SERVER-60715 Access of array fields is slow in SBE... Closed
Operating System: ALL
Sprint: QE 2022-10-03
Participants:
Story Points: 0

 Description   

Summary: accessing a sub-field is ~20-30% slower in SBE compared to the classical engine.

 

Create a collection with 10^6 documents like this: { a: Random.randInt(10), e: { x: Random.randInt(10)}}

Let the collection's namespace be "sbe-perf.LS", run against it the following benchmark:

benchRun({parallel: 1, seconds: 5, ops: [{op:"find", ns:"sbe-perf.LS", query:{"e.x":7}, readCmd: true}]})

results:

"queryLatencyAverageMicros" : 678104.625,
"totalOps" : NumberLong(8),
"totalOps/s" : 1.4746812891147691,

The results of the benchmark in classical engine are:

"queryLatencyAverageMicros" : 481276,
"totalOps" : NumberLong(11),
"totalOps/s" : 2.0777796016065393,

The top CPU consumers in SBE mode:

+ 23.49% mongod [.] mongo::sbe::vm::ByteCode::runInternal
+ 6.51% mongod [.] mongo::sbe::ProjectStage::getNext
+ 5.20% libc-2.27.so [.] __strlen_avx2
+ 5.06% mongod [.] __wt_btcur_next_prefix
+ 4.86% mongod [.] mongo::sbe::vm::ByteCode::run
+ 3.08% mongod [.] mongo::sbe::vm::ByteCode::getField
+ 2.85% mongod [.] __unpack_read
+ 2.73% mongod [.] __wt_cursor_get_valuev
+ 2.55% mongod [.] mongo::WiredTigerRecordStoreCursorBase::next
+ 2.37% mongod [.] mongo::sbe::TraverseStage::traverse
+ 2.16% mongod [.] __wt_cursor_get_keyv
+ 2.09% mongod [.] mongo::sbe::ScanStage::getNext
+ 1.91% mongod [.] mongo::sbe::bson::advance
+ 1.86% mongod [.] __wt_txn_read
+ 1.83% mongod [.] mongo::sbe::ProjectStage::open
+ 1.61% mongod [.] mongo::sbe::LimitSkipStage::getNext
+ 1.52% mongod [.] mongo::ElapsedTracker::intervalHasElapsed
+ 1.49% mongod [.] mongo::sbe::LimitSkipStage::open

The generated plan:

[1] filter {fillEmpty (s12, false)}
[1] traverse s12 s11 s6 [s4, s5, s7] {s12 || s11} {s12}
from
 [1] project [s7 = fillEmpty (isArray (s6), false)]
 [1] project [s6 = getField (s4, "e")]
 [1] scan s4 s5 none none none none [] @"c494dfc1-7ed7-45e7-a46d-b253a1e532db" true false
in
 [1] project [s11 = fillEmpty (s10, false)]
 [1] traverse s10 s9 s8 {s10 || s9} {s10}
 from
 [1] project [s8 = getField (s6, "x")]
 [1] filter {! s7 || isObject (s6)}
 [1] limit 1
 [1] coscan
 in
 [1] project [s9 = fillEmpty (s8 == 7, false)]
 [1] limit 1
 [1] coscan

Flamegraph is attached.



 Comments   
Comment by David Storch [ 26/Sep/22 ]

Cool, thanks for confirming!

Comment by Mihai Andrei [ 26/Sep/22 ]

That's right Dave; we more or less have coverage for the case covered in this ticket: https://github.com/mongodb/mongo-perf/blob/bfb260f9680b7e61ab21aecdfc5152220c20f8ea/testcases/simple_query.js#L897-L907

Comment by David Storch [ 26/Sep/22 ]

mihai.andrei@mongodb.com that's great news, thanks for looking into it! My only question is whether we should add a benchmark like this to our perf testing environment. We have the following tests with the "match_dotted_path" tag:

    - Queries.FindProjectionDottedField.Indexed
    - Queries.PointQuerySubField_CollScan_LL
    - Queries.PointQuerySubField_CollScan_LLR
    - Queries.PointQuerySubField_CollScan_LS
    - Queries.PointQuerySubField_SingleIndex_LL
    - Queries.RangeQuerySubField_SingleIndex_LowSelectivityMatch_LL

If I understand correctly, we don't need to add a benchmark because this is quite similar to the Queries.PointQuerySubField* tests. Is that right?

Comment by Kyle Suarez [ 21/Sep/22 ]

Assigning to david.storch@mongodb.com to verify that traverseF()-ification has improved this performance. CC mihai.andrei@mongodb.com, andrew.paroski@mongodb.com

Comment by Kyle Suarez [ 22/Oct/21 ]

ethan.zhang, eric.cox and irina.yatsenko, we are sending these SBE performance issues to the $group epic. Let us know if you think it belongs in a separate project.

Generated at Thu Feb 08 05:50:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.