[SERVER-40298] Track transaction size on 4.0 Created: 22/Mar/19 Updated: 29/Oct/23 Resolved: 29/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.9 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||||||||||||||
| Sprint: | Repl 2019-04-08 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Adding metrics around the size of transactions could help us determine what use cases to optimize for. Metrics for the last run transaction:
There will be a new serverStatus section transactions.lastCommittedTransaction:
|
| Comments |
| Comment by Githook User [ 29/Mar/19 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 26/Mar/19 ] |
|
Since we want these metrics on 4.0 quickly, and there is code motion on 4.2 due to Larger Transactions, I will implement this on 4.0 and forward-port if desired. |
| Comment by Tess Avitabile (Inactive) [ 25/Mar/19 ] |
|
Metrics for the last run transaction will allow us to determine typical transactions workloads, so that we can target performance work toward those workloads. We considered instead outputting histograms of #ops and size of oplog entries, but we wanted to capture the relationships between these two metrics. We felt that capturing the last run transaction would allow us to decide what axes to look at after we have the data. Since this information may only be useful for the Replication and Product teams, we could consider only providing it if requested and not documenting its existence (though we would need to change our data collection to request it). |
| Comment by Bruce Lucas (Inactive) [ 25/Mar/19 ] |
Generally speaking, cumulative metrics are preferred because they allow computing and charting averages over arbitrary sample intervals without sampling artifacts. For write concern we could record cumulative number of transactions for each write concern. Is there a specific use case that requires instead metrics for the last run transaction? |