performance

Heroku is a great platform if your app conforms to their expectations, but their dyno abstraction is somewhat leaky. It is surprisingly easy to deploy an application that behaves differently than you’d expect despite their documentation’s warnings about shared CPUs. In this post, I share some research on the performance/behavior of their various dyno classes and how I think about selecting dynos for different workloads. If you’re familiar with Heroku’s platform, I suggest skipping ahead to exploring CPU-intensive workloads.

Approximate Set Membership Several years ago I was hard at work building a near-realtime database of events happening around the world. This was a classic crawling problem, where I’d need to make sure I’m not checking the same location for events twice, or looking for events hosted by the same person twice. Initially the team and I were able to get away with using a regular Set for this, but as we scaled up to handle millions of sources this approach broke down.