I ran an experiment or two to see what the impact was on regular traffic when $queryStats is run and it seems we have an opportunity to reduce the impact (aside from already-filed SERVER-77567).

I noticed that we acquire the lock for a single partition at a time, but then we go through and compute the hmac-transformed key for each entry still while holding the lock. This should not be necessary, but will take some care to get right.

Here is where we do the hmac-intensive work: https://github.com/10gen/mongo/blob/505d34325477993864f4c8ead7878dda662ed9d5/src/mongo/db/pipeline/document_source_query_stats.cpp#L177

You can see it is within scope of the 'onePartition' locked object, preventing any progress for queries which would need to record metrics in that partition.

I think what should be done is:

• Reduce the critical section to only acquire the things we need to do our computations. Namely, rather than producing a vector of Document result objects during the critical section, only collect shared_ptr<QueryStatsEntry>}}s and {{metrics->toBSON() while holding the lock.
• Make sure we don't have race conditions by:
  • using shared_ptr to ensure the QueryStatsEntrys do not get evicted and freed out from under us
  • Make QueryStatsEntry::keyGenerator be const to prove/enforce that there will not be any data races between ongoing metric recording and us calling 'computeQueryStatsKey()' - which we will now do outside of the lock.