Reading time 5 min

Ruby on Rails

At some point or another, most people will run into a web application that just seems bleh. Maybe it’s because logging in or posting a form takes forever, the website frequently crashes, or maybe it’s even because your data gets stolen.
All of these issues can arise if the software running the website doesn’t stay up-to-date with the dependencies it uses, and our Rigor Labs projects are no exception.

Rigor Labs is a collection of free tools designed to help users find performance issues with their websites. Our different labs are:

Rigor Labs runs on a framework called Ruby on Rails. Built on the programming language Ruby, Ruby on Rails is a pragmatic, powerful, MVC driven, and easy-to-use web framework that has been explosively popular since its inception in 2004.

Recently we upgraded Rails from version 3.2.13 to 4.2.6 – a huge leap. We also decided to upgrade our Ruby version from version 2.0.0 to 2.3.1. We expected major performance improvements across the board, but what we got were major improvements in some places and lost performance in others. In this post, we walk through the major changes introduced in each step, what we expected to get, and what we actually got. Let’s dive in!

The Upgrade Process

When we started the upgrade, we expected to run into a myriad of issues that would require us to change our existing application code, but this was not the case. The biggest roadblock we ran into was upgrading our gems to work with our now Rails 4 app.

We started by upgrading coffee-rails and sass-rails to support the new Rails version and then ran into an interesting issue where puma 3.4 would cause a kernel panic on OSX El Capitan. Apparently this was an existing issue that was hard to reproduce, so in the interest of time, we decided to downgrade puma.

Once our gems were working well together, we had to change our Rails configuration files to remove deprecations. This was as simple as creating two new vanilla Rails applications, one for each version, and comparing the differences in configurations. We only found a handful of differences: namely whiny_nils no longer being supported and eager_load having to be configured for each environment.

Labs is a small project and our experience upgrading major Rails versions is certainly not indicative of how complicated the process could be for larger applications.

Performance Comparison

As a performance company, we’re always looking to measure and improve performance across our applications. In keeping with this, we wanted to ensure our upgrades had a significant effect on the performance of Rigor Labs.

For our tests, we used rack_mini_test. It acts as the topmost middleware in Rack-based applications and gathers timings, displaying them directly on the page being rendered. Pretty cool!

We installed rack_mini_test on two Git branches: one that held our code running on Rails 3.2.13 with ruby 2.0.0 and another running Rails 4.2.6 and ruby 2.3.1. Each branch was run in a production environment to simulate production timings.

Landing Page

Pre Upgrade
landing_page.png

Post Upgrade
landing_page.png

The landing page is the first page the user will see, and it’s important that it’s fast to keep the user engaged. With the updated app, we were very excited to see a 6ms increase in performance for this page.

Online Curl

Pre-upgrade
onlinecurl.png

Post-upgrade
onlinecurl.png

This is where we can see the biggest improvement in performance. You’ll notice that after the upgrade, the application isn’t re-rendering curl_requests/_form. This is due to Rails caching features. These partial views are rendered once and are then cached in the browser so that they don’t have to be rendered again. This feature was available in our old version of Rails, but we only took advantage of it after the upgrade.

Har Diff

Pre-upgrade
hardiff-new.png

Post-upgrade
hardiff-new.png

We can see that the major difference in times comes from the Executing action: new process. This improvement was a result of the upgrade to Ruby, as this process only involves creating a few instances of some models and generating tokens for them.

Pre-upgrade
hardiff-show.png

Post-upgrade
hardiff-show.png

This is where the Ruby upgrade gave us a significant performance boost. Comparing HAR files relies heavily on parsing data from an IO-like object. In the release notes for Ruby 2.3.0, we can see that this version reduced calling overhead for Socket and IO-like objects, and as a result, it cut the time needed to parse HAR files in half.

These are only a few examples of how upgrading our application improved performance, and we’re not done improving on what we have so far. Rails 4 introduced many new features that we want to take advantage of in order to provide an even more performant tool.

What’s So Great About Rails 4 Anyway?

Rails follows semantic versioning and upgrading from 3.2.13 to 4.2.6 is considered a major upgrade.

Starting with version 4.0.0, the Rails Core Team introduced new features, deprecations, and security upgrades:

  • Mass assignment of attributes for Rails models from the controller was disallowed in favor of strong_parameters
  • Rails was made more lightweight by extracting out multiple features into ruby gems
  • HTML entries are now escaped by default, helping to sanitize user input
  • Security headers are now included with every request by default

A lot of these improvements didn’t affect Labs directly. Other than some syntax changes, the application code was relatively untouched.

What Rigor Monitoring Tells Us

We have multiple Real Browser Checks in Rigor Monitoring set up to monitor Rigor Labs. These checks keep track of metrics such as page and DOM load times, errors reported, how many and what type of resources are loaded, and page size.
Online_Curl_(RB)_Page_Performance_Page_size_Mon_May_23_04-00-00_UTC_2016_to_Tue_Jun_07_03-59-59_UTC_2016.png

The snapshot from Rigor Monitoring shows the page size for one our Rigor Labs: Online Curl. The blue bar running through the graph is an annotation showing when we deployed our upgrade.

One of the dependencies we had to upgrade was uglifier which handles minifying our Javascript assets when we send them to the browser. We can clearly see the savings gained from upgrading this one dependency – a 50% reduction in page size!

Conclusion

Upgrading applications can be a long and involved process or a short and easy one. Luckily for us, our upgrade was short and easy. With the immediate performance benefits we’ve seen, it’s apparent that this was a worthwhile effort. We continue to make Rigor Labs as modern as possible, and with these upgrades we are well on our way to achieving that goal.

Suggested Blog Posts

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design...

Read More

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More

Optimization Options not Always Optimal

Web designers and developers are always looking for ways to speed up their page load times. Yahoo has an excellent article written on the best practices for speeding up your page. How do you know if implementing one of their suggested practices will...

Read More