Problem

On-CPU profiling of a 128-thread pure-read workload shows 0.24% cumulative CPU in LogicalSessionCacheImpl::vivify(), dominated by:

• 25.75% of samples in pthread_mutex_lock — contention on the global _mutex
• 44.14% of samples in an absl::flat_hash_map lookup

vivify() is called on every operation with a session ID. On connection-pooled workloads, the same connection sends the same session repeatedly, yet every operation pays the full mutex + hash lookup cost just to call setLastUse(now).

The session timeout is 30 minutes and refresh interval is 5 minutes — per-operation updates are orders of magnitude more frequent than necessary.

Solution

Add a thread_local pair of (last-vivified LogicalSessionId, coarse Date_t) in logical_session_cache_impl.cpp.

Before acquiring _mutex, check if the same session was vivified within the last 5 seconds. If so, return Status::OK() immediately — skipping the lock and hash lookup entirely.

Why this is safe:

• The sync executor uses one thread per connection, so thread_local maps 1-to-1 with a client
• Under the async executor it silently degrades to a no-op — no correctness risk