If you have limited time and resources, a "barbell" strategy towards performance work often yields the best results.
|
|
If you've never heard of a barbell strategy, the idea comes from finance, where it was used to describe an investing strategy where one invested in short and long-term bonds, but not intermediate-term. Outside of finance, it means a strategy which avoids the "middle" path.
In performance work, I often find that work in the "middle" of the effort distribution lacks the effort-to-benefit ratio of the "low" and "high" effort ends.
Here's some examples of what I consider "low effort" performance work:
- Tuning request queueing correctly
- Changing environment variables
- Using jemalloc
- Setting up a CDN
And medium effort:
- Fixing N+1s/optimizing ORM usage
- Using flamegraphs to determine why a controller is spending lots of time executing Ruby
And high effort:
- Re-architecting the site to use Turbo
- Changing all of your site's Javascript tags to use async
- Adding threaded concurrency (going from 1 thread to N threads)
Low effort performance work is almost always my first priority. While the risk and effort required to implement these changes is low, sometimes the benefits are massive. Jemalloc can cut memory usage by 50%. Fixing request queueing and autoscaling configuration can revolutionize how you scale. But these things are usually not actually that hard to implement. And sometimes, when you try these "tricks", they don't have a benefit. But who cares? You wasted an hour or two, at most, giving it a shot.
High effort performance work offers a different time/benefit tradeoff. These efforts take multiple man-months to implement. But, once they're live, the benefits almost always completely change the site's performance, halving load times, etc. The work is riskier than low effort work, but the benefits can hopefully match.
Medium effort work is often less clear. Often, I see engineers fixing performance issues on specific backend endpoints, but then they see no impact in production, particularly on Real User Monitoring (i.e. browser performance) data.
This isn't to say that medium-effort performance work is less important or doesn't have any benefits - but often, I find it's more appropriate to start with low-effort work, tuning and guessing at quick fixes, and then immediately to shift into a much larger picture, big-sky-thinking mode where everything is on the table and nothing is sacred. "If you had to halve load times across your entire site, how would you do it?" Medium-effort performance work is best explored once those paradigm-shifting ideas have been exhausted, or deemed beyond the organization's capabilities.
Beware the middle.
-Nate
|
|
|
|