The RailsNotes Newsletter 🟥 ISSUE #13

🟥 ISSUE #13 (Performance Optimization, YJIT, Production Rails, Count vs Size)

Author

Harrison Broadbent
September 29, 2023

Despite being a bit of a novice train enthusiast, these aren’t the Rails we’re interested in optimizing today 🚞

— SPONSOR —

Payroll by Revelo enhances your team's performance and saves you money with a 100% safe, compliant payroll entourage (plus we’re packed with perks to delight and retain talent).

The best of it? It’s free, and AI handles the hard work!

Welcome to The RailsNotes Newsletter — Issue #13! This edition is all about performance and Rails in production 🚂

We’ve all heard what people say — “Rails doesn’t scale”, “Rails is slow” etc etc. Clearly, I disagree, but I don’t think that should stop you from trying to optimize the performance of your Rails apps.

Fortunately, you’re not the first person to have some Rails performance trouble. There are some incredible resources out there to help you build and optimize your Rails apps — tracking down N+1 queries, caching with a CDN, using YJIT and jemalloc , and many more.

I’ve spent a decent chuck of time tuning performance on my own, and it’s always an interesting time. For RailsNotes UI, since 99% of the content is static assets, caching with a CDN was by far the biggest win. Most of the time though, database performance is the biggest concern (N+1’s, tuning threads and connection pools, etc).

If this sounds daunting, don’t worry! I’ve got some great articles here to help wet your feet. And if you’re a jaded, weathered senior dev who’s seen it all, these articles are detailed enough that I’m sure you’ll learn something too.

Let’s go!

side note: the featured article this week is 1. incredible and 2. not a RailsNotes article. Writing time is getting hard to come by for me these days, but fortunately, I’ve got heaps of great Rails articles saved up and ready to share with you!

— ✨ FEATURED ARTICLE —

Performance tuning isn’t normally as exciting nor as chaotic as this picture might suggest, but I hope these articles will give you more of the former (and less of the latter!)

So you want to speed up your Rails app? Start here. No seriously, this is probably the best place on the entire internet to start. Paul is a Rails performance machine, his blog is packed with Rails performance tips, and this article is a great introduction into the world of Rails performance.

Paul walks you through some of the key areas for Rails performance tuning — the frontend, database and server.

Adding a CDN or optimizing your top-few slow SQL queries are probably the net-largest performance wins you’ll ever see, and Paul does a good job introducing you to methods for doing this. Plus, he has heaps of great links to other articles of his, if you want to go deeper into a particular method (you will).

Absolutely worth a read! Even if this article isn’t quite what you need, there’s bound to be something else on his blog that you discover (it’s truly a treasure trove).

— 🌐 MORE ARTICLES —

If Paul’s article was a sushi restaurant, then this article is a buffet. It’s packed with clear, tacit tips that you could implement today to speed up your app.

I stumbled on this article while researching this newsletter, and I’m glad I did — Peter has written a brilliant guide on Rails performance tuning; it’s packed with great tips (I counted 27), and he gives you actual code snippets and examples to make it extremely clear what you actually need to do (often the hardest part!).

Another Rails legend, Andrew Kane, has put together this brilliant best-practices guide for running Rails in production. He touches on the performance stuff a little bit, but mainly covers everything else you should know about going live — Logging, Monitoring, Timeouts, Feature flags and more.

You probably know Andrew from his prolific GitHub activity, and he has tons of helpful gems which he pulls together in this guide — safely, pghero, strong_migrations and more.

Shopify has been doing some incredible work to make Ruby faster, and yjit is their magnum opus. With Ruby 3.3’s YJIT looking to be even faster, this article is a cool look at things to come (and a great reminder to give yjit a try if you haven’t already!).

The entire Rails at Scale blog is worth a read if you’ve got time, but this article (apart from being the most recent) is a great deep-dive. They report up to 13% faster execution over YJIT 3.2 🤯, and DHH recently tweeted about Basecamp seeing similar speedups.

— ⚒️ HANDY TIP — 

→ Prefer .size over .count (almost always)

This tip is an easy one!

Prefer calling .size to count a collection of objects over .count. Here’s a great explanation why (from a great blog), but essentially, .size will check to see if the records we’re counting are already loaded. If they are, it will just use them, rather than calling the database again.

In contrast, .count always creates a COUNT query, ignoring any preloaded data and costing an extra DB hit.

It’s a small thing, but an easy way to lighten the load on your database. 

@messages = current_user.messages

# Bad
@messages.count #extra COUNT query

# Good
@messages.size #no extra query (if data already loaded)