Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-53679

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

      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@mongodb.com Janna Golden
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: