[SERVER-35157] Add transactions latency tracking to OperationLatencyHistogram Created: 22/May/18  Updated: 29/Oct/23  Resolved: 05/Jul/18

Status: Closed
Project: Core Server
Component/s: Diagnostics, Replication
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Task Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Nathan Louie
Resolution: Fixed Votes: 0
Labels: global-txn-metrics
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-35159 Track transactions latency and add to... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-07-02, Repl 2018-07-16
Participants:

 Description   

To support the tracking of transaction latency information in serverStatus, we want to add a transactions section to the OperationLatencyHistogram class. We can add a HistogramData _txns member variable, analogous to the existing _reads, _writes and _commands variables. We will also need to add a new Command::ReadWriteType type that represents a multi-document transaction.



 Comments   
Comment by Githook User [ 16/Aug/18 ]

Author:

{'username': 'nxlouie', 'email': 'nathan.louie@10gen.com', 'name': 'Nathan Louie'}

Message: SERVER-35157 Add transactions latency tracking to OperationLatencyHistogram

(cherry picked from commit 96c5d840db4f4279cd9fc8ffe4bdfdc60fcd3984)
Branch: v4.0
https://github.com/mongodb/mongo/commit/8376aa91cb065a7c23d5dcec56e0ab54d30dc81d

Comment by Githook User [ 05/Jul/18 ]

Author:

{'username': 'nxlouie', 'name': 'Nathan Louie', 'email': 'nathan.louie@10gen.com'}

Message: SERVER-35157 Add transactions latency tracking to OperationLatencyHistogram
Branch: master
https://github.com/mongodb/mongo/commit/96c5d840db4f4279cd9fc8ffe4bdfdc60fcd3984

Comment by William Schultz (Inactive) [ 30/May/18 ]

To Kyle's point, it is simply the first command of a transaction that marks its "start". The latency should be measured from that time until the commit or abort event.

To Bruce's last comment, yes I think that is roughly correct, but that will be fleshed out separately, in the tickets for tracking abort causes and their counts.

Comment by Bruce Lucas (Inactive) [ 24/May/18 ]

There's no startTransaction command as such, but indeed commitTransaction and abortTransaction will show up in the command section.

I think that transactions that time out should be counted in transactions.totalAborted, and there should be a transactions.abortCause.timedOut counter, alongisde transactions.abortCause.aborted (for explicitly aborted transactions). william.schultz, do you agree? (Also I think this comment goes with a different ticket).

Comment by Kyle Suarez [ 23/May/18 ]

Cool, thanks for confirming. Also, startTransaction, commitTransaction and abortTransaction are all themselves commands, so I presume they will show up in the "command" section as well.

The transaction reaper will have to be updated to make sure it records the total time of the transaction when killing it. This reaping probably should not count as an explicit abortTransaction, though.

Comment by Bruce Lucas (Inactive) [ 23/May/18 ]

Yes, that's the intent.

Comment by Kyle Suarez [ 23/May/18 ]

To clarify, this section tracks the latency of an entire transaction, from startTransaction to commit or abort? For example, if a user does

session.startTransaction({...});
session.getCollection("coll").find();
session.abortTransaction();
 
session.startTransaction({...});
session.getCollection("coll").insert({x: 1});
session.getCollection("coll").find();
session.commitTransaction();

then the global operation latency histogram will have entries for two reads, one write and two transactions?

Generated at Thu Feb 08 04:39:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.