Spike in response time when multiple threads update a single Clojure ref via dosync

When a Clojure application processes concurrent requests that each perform a write to a shared ref inside a dosync block, the measured latency per request remains low in single‑threaded runs but rises sharply as the number of simultaneous threads increases.

The goal is to determine whether this latency increase stems primarily from STM retry cycles, from the overhead of ref‑set dependency tracking, or from other factors such as transaction length or contention on the underlying lock‑free structures. The system under consideration uses the default STM implementation, with no custom retry policies, and the dosync blocks contain only a single alter operation on the ref.

• What proportion of the observed latency can be attributed to transaction retries versus other STM bookkeeping?
• How does varying the number of threads or the frequency of requests affect the retry rate and overall latency?
• Would moving the write operation outside of dosync (e.g., using an atom) eliminate the latency spike, and if so, what does that indicate about the STM contribution?