No-op for filling in destined recipient for insert oplog entries adds overhead on shardsvrs not running resharding

XMLWordPrintableJSON

    • Fully Compatible
    • ALL
    • Sharding 2021-02-22, Sharding 2021-03-08, Sharding 2021-03-22, Sharding 2021-04-05
    • 0
    • 1
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Splitting this off from SERVER-53678 because the change is more involved.

      getDestinedRecipient() is called by OpObserverImpl for all write operations and returns boost::none when there isn't an ongoing resharding operation. Making it so CollectionShardingState::get() and CollectionShardingState::getCollectionDescription() are only called once for each OpObserverImpl::onInserts() call (all of the inserts are to the same collection) would likely address this performance regression. It may be worth noting that OpObserverShardingImpl::shardObserveInsertOp() calls CollectionShardingRuntime::get() once per document being inserted too so addressing both interfaces could be a net performance win.

              Assignee:
              Janna Golden
              Reporter:
              Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: