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

    XMLWordPrintable

Details

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

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              janna.golden@mongodb.com Janna Golden
              max.hirschhorn@mongodb.com Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: