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
related reading
- Rewriting Bun in Rust | Bun Blogbun.com
- abseil / Performance Hintsabseil.io
- NYSRGnotes.ekzhang.com
- My Thoughts on the Bun Rust Rewriteandrewkelley.me
- How Mozilla’s Rust dramatically improved our server-side performance | Figma Blogfigma.com
- CRDTs go brrrjosephg.com
- Locking in WebKit | WebKitwebkit.org
- A data race that doesn't compilecorentin-core.github.io
- Shared-State Concurrency - The Rust Programming Languagedoc.rust-lang.org
- abseil / Performance Hintsabseil.io
- How to do distributed locking - Martin Kleppmann's blogmartin.kleppmann.com
- Spinlocks Considered Harmfulmatklad.github.io