When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.

Imagine your customers are complaining that a few specific pages in your application take forever to load and you get to work to fix the issues. But there is a problem. You don’t know where to begin. If this journey of seeking truth, I mean answers, interests you, then read the rest of the article.

There has been a lot of conversations on social media about the “NoBuild” approach: using native browser features and plain CSS+JavaScript to avoid a precompilation step for our assets.

In many cases, it’s not easy to move to a “NoBuild” setup (and in some cases it’s not even possible depending on the application’s needs), and we can still aim to make the assets:precompile task as fast as possible if we can’t eliminate it.

In this article we’ll explore some areas for optimization using one of our applications.

In a previous article, we listed down common culprits that led to a sub-optimal performance in Rails applications. One of the culprits was missing or incorrect indexes.

Therefore we thought it would be very useful to have a handy reference to the different kinds of indexes, when you should use them and maybe even when not to use them.

Is your goal to rank first on Google? Have you already tried using the best keywords and strategies to rank higher but none of that has worked? It might be because your LCP, or Largest Contentful Paint, score is high and needs improvement.

When it comes to improving application performance and areas to focus on, I would recommend looking at the APM data, and then deciding which areas to prioritize.

However this article isn’t about where to focus efforts, but rather a compilation of techniques to improve your application’s performance, from tackling common problems like N+1 queries and database indexing to leveraging the jemalloc memory allocator. Let’s look at these performance-boosting strategies designed to fine-tune your application.

Here at FastRuby.io we always try to have our own applications in such a state that they can always be pointed to as models in terms of performance and accessibility.

One of the tools we use to achieve that is our CDN. After all, considering we have clients everywhere from the US to New Zealand, we want anyone perusing our websites to have good loading times for the pages and, especially, the assets.

However, no matter how thorough, one always misses a spot or two.

When we allow users to upload images, they usually upload files without any optimization for the web. It’s up to us to add some measure to prevent those images from slowing down our app. Luckily, the different gems commonly used to handle user uploads also give us solutions for this problem.

This is the second part of the Optimizing Images series. In the first article we talked about the basic concepts and techniques to optimize raster images, and today we’ll talk about techniques to optimize SVG files.

Imagine this scenario: you open a website on your phone, you see an image loading really really slowly, you wonder what’s going on and download the image to see more details… turns out the image is 3000x3000px with a size of 1.5Mb!

So, let’s talk about different ways to optimize images, common problems, and ways to find these issues early.

I’m seeing a lot of disappointment about the speed of Ruby 3 out there. I think there are a lot of reasons for that, and I think they’re worth looking at.

So: why wasn’t Ruby 3 faster? Did it break its promise? (Spoiler: I don’t think so, but I understand why some people do.)

If you’ve been following me awhile, you know that I was hired by AppFolio years ago to measure Ruby 3’s performance, especially on Rails. This has been a long trip. And that very first project is finally over: Ruby 3 exists and I can check its final, released Rails performance.

If you have been following along, the numbers in this post won’t surprise you. But it’s important to do the final measurement. If you haven’t been following, this will bring you up to date.

Ruby 3x3 is coming in about a month. One of its new concurrency primitives is Ractors, which used to be called “Guilds.” (The other new concurrency primitive is Autofibers.)

Ruby has a Global VM Lock (GVL), also called the Global Interpreter Lock (GIL), that prevents running Ruby code in more than one thread at once. So Ruby threads are great for I/O like waiting on files or databases. And they’re great for cases where a C extension can keep calculating in a background thread while a foreground thread runs Ruby. But you can’t do calculations in Ruby in more than one thread at once within the same process.

At least not until Ruby 3 and not without Ractors.

Great! Now how fast is the current implementation of Ractors?

Do you ever look at the list of Amazon EC2 instance types?. Those are sizes of virtual machine you can rent to run your code on. Well, okay, they’re groups of sizes, since each one of those headings has a bunch of different sizes of VM…

So what type of EC2 instances should you run your Rails app on?

The answer is simpler than it looks.

Do you love numbers? I love numbers. Do you hate numbers? Skip to the bottom, there’s a nice summary paragraph. Do you really really love numbers? There are raw data dumps including all my intermediate results.

The new Ruby 3.0 preview is out! Woo-hoo!

If you’ve heard of me, you know performance is kinda my thing, especially Rails performance on large apps. I do other stuff too, but I got paid to do that for years (thanks, AppFolio!), so I’ve written a lot about it.

How does the new preview’s performance stack up on Rails? And how reliable are these numbers?

Here we continue with the series of articles where we talk about how minor adjustments in the code can lead to major performance improvements.

In this article we’ll focus on the use of ActiveRecord::Batches#find_each when it comes to iterations across a large number of records.

Some time ago we wrote a couple of Tips for Writing Fast Rails. It was about time we wrote part two so here it is!

Rails is a powerful framework. You can write a lot of features in a short period of time. In the process you can easily write code that performs poorly.

At OmbuLabs we like to maintain Ruby on Rails applications. In the process of maintaining them, adding features and fixing bugs, we like to improve the code and its performance (because we are good boy scouts!)

Here are some tips based on our experience.

Prefer where instead of select

When you are performing a lot of calculations, you should load as little as possible into memory. Always prefer a SQL query vs. an object’s method call.