[SERVER-47802] Destroy opCtx after responding to clients Created: 27/Apr/20  Updated: 29/Oct/23  Resolved: 14/May/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.4.0-rc7, 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Amirsaman Memaripour Assignee: Amirsaman Memaripour
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Problem/Incident
Related
related to SERVER-48295 Remove operation key in killAndDelist... Closed
related to SERVER-56737 Provide a separate path for delisting... Backlog
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Service arch 2020-05-04, Service arch 2020-05-18
Participants:
Linked BF Score: 0

 Description   

Destroying OperationContex before responding to a client (see here) makes the cost of reclaiming resources visible to the client, and negatively impacts the performance. We should investigate the possibility of postponing the destruction until after the response has been sent to the client.



 Comments   
Comment by Benjamin Caimano (Inactive) [ 15/May/20 ]

Yep, amirsaman.memaripour has expressed the changes accurately. Thanks for responding so quickly!

Comment by Amirsaman Memaripour [ 15/May/20 ]

Sure, this ticket was a quick performance improvement for those who don't use pipelining. We'll hopefully address batching/pipelining in future efforts. Thanks for pointing this out matt.broadstone.

Comment by Matt Broadstone [ 15/May/20 ]

Thanks for the quick reply Sam. I also just wanted to get it on your radar that there are a lot of users out there that depend on pipelining (for better or worse), so it's probably worth considering them in the future to some degree. We're working hard to migrate them away from it, but can't really force people to upgrade if they don't want to.

Comment by Amirsaman Memaripour [ 15/May/20 ]

matt.broadstone I don't think the changes would have any negative impact, even in presence of pipelining (batching). This patch only moves the cost of deleing opCtx around, and without batching, we can utilize the gap between requests to do the destruction work. ben.caimano, please correct me if I'm missing something here.

Comment by Matt Broadstone [ 15/May/20 ]

ben.caimano the node driver does still pipeline, and will continue to default to doing so until we can change the default in the upcoming breaking 4.x release. I haven't followed this very closely, but did we make changes here that would negatively impact those users?

Comment by Githook User [ 14/May/20 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-47802 Destroy opCtx after responding to clients

Postpone destruction of opCtx until after responding to clients to
reduce the cost of destroying opCtx on the critical execution path.

(cherry picked from commit b77252a641838f43e3c09796a09be22ab8f44e1c)
Branch: v4.4
https://github.com/mongodb/mongo/commit/91cebe1fe7661260615ec524e17ccfdc2df10387

Comment by Githook User [ 14/May/20 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-47802 Destroy opCtx after responding to clients

Postpone destruction of opCtx until after responding to clients to
reduce the cost of destroying opCtx on the critical execution path.
Branch: master
https://github.com/mongodb/mongo/commit/b77252a641838f43e3c09796a09be22ab8f44e1c

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