Performance First Rails – Lessons From Production

This is a work in progress. These are the lessons I’ve picked up from running rails in production.

My Rails Performance Lessons

1. Always measure the thing you want to improve.

• Test against production. It’s the only environment that matters.
• Finding the right worker count is trial and error. Experiment.

2. Start with the database. It’s always the database.

• Use CTEs to rewrite queries with subqueries.
• Unindexed queries hurt the system’s overall performance. Fix this first.
• Tune your database settings away from the defaults.
• Create partial indexes for frequently queried accounts.
• Use pluck and send less data across the wire.
• Denormalize the most requested data (joins are expensive).
• Use different settings for different workloads.

3. Cache aggressively: the less work your DB does, the faster everything gets.

• HTTP caching.
• Cache query results.
• Cache HTML fragments.
• Cache API response data.
• Split caching across multiple Redis instances.

4. Controlled parallelism is great.

• Separate Redis for workers vs. cache vs. sessions.
• You really only need three queues: fast, slow, and hi-mem.
• You can add a vip queue, but don’t get carried away.
• Run different workloads on different hosts.

5. Make the most of Ruby.

• Ruby 3.5 is coming and it’s faster.
• Use jemalloc and YJIT, or whatever the latest JIT is.
• You can tune jemalloc, but only a little.
• Use jsonapi-serializer — it’s fast.

6. Do not use your database as a queue.

• Don’t use your database as a queue. It exists to serve data.
• Do not use delayed_job. Ever.