The bosses are pinging you that the Rails app is slow. Customers are complaining. Panic sets in. People are upset. You start reaching for anything and everything to get it faster.

A lot of folks first move is to start upgrading Rails and Ruby. Then your bosses are quizzing you on the effectiveness of the upgrade.

Someone recently asked on StackOverflow:

"I want to compare the performance improvement I obtained by upgrading the rails and ruby version. Is there any best tool to achieve this?"

Question was deleted however. Which is a shame. Because it's a question a lot of folks are asking or being asked. But, the question does bring up a number of concerns that I see over and over again. Let's unpack them.

Monitoring Doesn't Have To Be Expensive

First let's talk about getting performance monitoring setup in the first place.

This is easy. And often free. You've got tools like New Relic or Skylight or AppSignal. New Relic can be a ton of money for the full product, but New Relic has a Lite plan (on Heroku) that will at least tell you what your average response times are like in a 24 hour period.

One interesting hack for tools like these: they don't have to always be running. Sure, it's awesome to have a view of your entire application at all times, but if you're in a budget crunch, use deploy scripts or some kind of instrumentation to turn off these tools before they pass their requests/month.

For example, at Highrise, we had created deploy scripts to make sure New Relic was only deployed to a fraction of our many servers. The setup still created a great sample of data to understand our app without breaking the bank.

So, there's no reason you shouldn't have performance monitoring tools running. If you did, you'd know what kind of impact you had with your upgrades.

Test It

Next, Rails has had performance testing baked into it since version 3. It's now separated from the main Rails stack but it's easy to add as a gem: https://github.com/rails/rails-perftest

Run that against your apps, especially areas you know are killing your performance, and you should have your answers. That gem also mentions a few other great resources to test and profile apps.

Rails Makes Us Lazy

What concerns me the most though, when folks complain about slowness, is that an upgrade of Rails probably isn't the solution to what ailed them in the first place.

"Slowness" complaints are often two things. True application slowness or perceived slowness.

Perceived slowness happens when we as designers get a little too fancy with things like animations and steps. Users complain about things feeling slow. Even though this really isn't a code problem as much as it's a we've-added-things-that-just-bog-down-the-time-it-takes-for-a-user-to-get-what-they-want problem.

We at Rockstar actually had this problem in the previous version of our marketing website. Our stakeholders complained of slowness. But really? It was things like the slow animated reveals of parts of the website, for no good reason other than it seemed fancy. Another "slowness" problem consisted of a giant, multi megabyte image that could have easily been a handful of KB.

There are a ton of easy things to eliminate perceived slowness. So make sure you dig deep into complaints to understand what you're truly battling.

The former issue however, app slowness, is rarely going to be improved by the significant amount you expect simply with a Rails upgrade. Sure, there are nice improvements to the framework over the years and Ruby just gets better. But, if you're in a battle to troubleshoot slowness in your app, there's a lot of things I'd worry about first over upgrades.

The leading cause of Rails app slowness (according to the American Rails Association of people writing this post) is simply because people making Rails apps aren't doing the hard work of understanding what's actually happening underneath.

I get it though. Rails makes getting an app off the ground extremely easy. We then get lazy in some of our software craft. So when things stop working well, it's easy to blame the framework instead of spending time understanding the nuts and bolts of what's going on underneath your app.

I'd say 80% of the time for your app slowness is just poorly optimized SQL queries. Again, something that's easy to screw up with Rails since Rails abstracts most developers away from the SQL they're generating. But if you spend more time pouring over and digesting those log files Rails spits out, you'll notice things like slow queries or a ballooning amount of queries - things often easy to fix using better indices, eager loading, or a judicious use of caching.

"Rails is slow" is a way too often cited complaint. But the funny thing is it's usually caused by the ease at which Rails can be used to build apps. Some of the more difficult things are abstracted away from us as developers. We then don't do the hard work of understanding what's happening underneath, and we fall into a trap where we just upgrade everything hoping for magic.

I'd exhaust the things mentioned above before hoping a Rails/Ruby upgrade is going to make my customers or bosses happier with the performance of my app.

P.S. Need extra eyes on a performance problem? Please reach out. We'd love to help.