[SERVER-81786] Avoid future and scheduling overhead on sync command path Created: 03/Oct/23  Updated: 04/Oct/23  Resolved: 04/Oct/23

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

Type: Improvement Priority: Major - P3
Reporter: Mathias Stearn Assignee: Backlog - Service Architecture
Resolution: Duplicate Votes: 0
Labels: perf-tiger, perf-tiger-handoff
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-81785 Avoid future and scheduling overhead ... Closed
Related
Assigned Teams:
Service Arch
Participants:

 Description   

Futures have a heavily optimized fast path for the case when they are already ready. It is intended to be essentially free in that case, while there is some unavoidable overhead in the case where it isn't yet ready at the time you chain additional work. This code is using a slower "not-ready-yet" path for futures, even though it triggers the chain before returning. Defuturizing or at least using makeReadyFutureWith() should be an easy win. Instead of doing this manually, consider just reverting this revert which reintroduced the suboptimal usage of futures here.

This patch to SessionWorkflow::_scheduleNextIteration will bypass the scheduler overhead and keep running eager futures for sync networking:

diff --git a/src/mongo/transport/session_workflow.cpp b/src/mongo/transport/session_workflow.cpp
index 7342a707866..3ddc787deff 100644
--- a/src/mongo/transport/session_workflow.cpp
+++ b/src/mongo/transport/session_workflow.cpp
@@ -809,7 +809,10 @@ void SessionWorkflow::Impl::_scheduleIteration() try {
         }
         if (useDedicatedThread()) {
             try {
-                _doOneIteration().get();
+                while (useDedicatedThread()) {
+                    _doOneIteration().get();
+                    _work = nullptr;
+                }
                 _scheduleIteration();
             } catch (const DBException& ex) {
                 _onLoopError(ex.toStatus());



 Comments   
Comment by Mathias Stearn [ 04/Oct/23 ]

Sorry, I got an error when submitting the new issue so I assumed it didn't go through and tried again. My bad!

Comment by Jason Chan [ 04/Oct/23 ]

The descriptions have slightly different text but I think this is a dupe of SERVER-81786 so I'm going to close this in favor of SERVER-81785. Feel free to re-open if this isn't the case mathias@mongodb.com.

Generated at Thu Feb 08 06:47:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.