A locking war story
We recently migrated JavaScript/SourceMap processing to Rust where we were hitting a lock contention problem in our processing infrastructure that kept people up for a few days. What happened, why and how did we solve it?
A locking war story | Sentry Blog Skip to main content ← Back to Blog Home We recently migrated the JavaScript and SourceMap processing from Python code over to Rust code, more specifically our Symbolicator service that is a powerhouse aimed at heavy processing. However, the first few days of pushing 100% of JavaScript events through this service kept our teams awake for far too long. Processing some of those events did not go as smoothly as it should have, and we were battling low throughput and increasing backlogs in our processing infrastructure. In the end, I tracked the root cause of that
Explore this link on the map →related reading
- Rewriting Bun in Rust | Bun Blogbun.com
- abseil / Performance Hintsabseil.io
- NYSRGnotes.ekzhang.com
- CRDTs go brrrjosephg.com
- Locking in WebKit | WebKitwebkit.org
- abseil / Performance Hintsabseil.io
- Shared-State Concurrency - The Rust Programming Languagedoc.rust-lang.org
- Spinlocks Considered Harmfulmatklad.github.io
- Unreliable Guide To Locking — The Linux Kernel documentationdocs.kernel.org
- Reading 16: Mutual Exclusionweb.mit.edu
- cbloom rantscbloomrants.blogspot.com
- Fearless Concurrency - The Rust Programming Languagedoc.rust-lang.org