Problem

Off-CPU profiling of a 100% read YCSB workload at 128 threads against a replica-set primary shows two separate VectorClock::_mutex contention sites in the per-request path that together account for 0.30% of off-CPU time per 305-second test window. readRequestMetadata → _advanceTime acquires the mutex on every incoming request to merge the client's gossiped $clusterTime, even though on a stable replica set the incoming clock values are almost always less than or equal to the server's current values — making the mutex acquire a no-op for the actual work. Symmetrically, appendClusterAndOperationTime → gossipOut → getTime acquires the same mutex on every outgoing response just to copy the 3-element _vectorTime array, even though those values change very infrequently on a stable cluster (ClusterTime advances only on writes/noop-writer; ConfigTime/TopologyTime are essentially static).

Solution

Add an array of three AtomicWord<uint64_t> shadow values alongside _vectorTime. The shadows are written under _mutex whenever any component of _vectorTime changes (in _advanceTime, _advanceComponentTimeByTicks, and _advanceComponentTimeTo). Two new lock-free read paths consume them: a precheck in _advanceTime that returns early when all incoming components are less-or-equal to the shadow (correct because the shadow is monotonically non-decreasing — a stale read can only cause a redundant mutex acquire, never a missed update), and a new getTimeRelaxed() method used by gossipOut to construct the response $clusterTime without locking. Per-component relaxed reads can yield a cross-component snapshot that's slightly skewed in time, but each component is gossiped independently and recipients take max(local, received), so this is safe. The pattern mirrors the accepted shadow design from SERVER-123415 (replcoord-lastapplied-atomic-timestamp-shadow).