Since version 3.0, the latencies reported in the logs and profiler have generally represented the entire operation latency, including any time spent acquiring locks. We separately report lock wait times in the locks section of the logs, system.profile, and serverStatus. However, often it is interesting to analyze the time an operation takes without including lock acquisition. For example, in the case of queues on a lock caused by a slow operation, this would help to identify which operations are actually taking a long time for the execution path to process, as opposed to those taking a long time because they need a lock which is currently held by another op.

If we decide to explicitly expose such a quantity, we should think through how to add it to the following debug mechanisms:

• Slow query logs.
• system.profile collection.
• db.currentOp().
• The top command.
• Global and per-collection latency stats.
• serverStatus().