Load Testing Ruby Apps for Black Friday

Is your website ready for Black Friday traffic? Rails is capable of serving a huge amount of traffic. This is already proven. To make sure your Rails application is ready, you should perform load testing and add more servers if needed.

Ideally, you would load test your application before you launch. But we know some things take more priority. There's always that feature you want to finish. There's a bug that needs to get fixed. Load testing gets pushed down the list. Until you hear your customers complain that the site is slow or not loading at all. You'll lose a lot of money if users can browse your products but can never complete the checkout process.

How do you know if your servers can handle your traffic? Let's find out.

Set Up a Test Environment

We will simulate a high number of users during testing so it is important to run the tests on a test environment and not your production environment. The test environment should be as similar as possible to the production environment. At Engine Yard, you can clone an environment which is an easy way to create a new environment with the same number and size of servers and same roles (app, background jobs, database).

Identify Metrics

Our goal is to prepare your production environment for a large amount of traffic. Two important metrics here are throughput (requests/second or requests/minute) and response time.

We use requests/minute instead of number of users because it's easier to measure requests than to track users. During the peak usage of your site, we want the response time to be the same or if it increases, the site shouldn't feel slow to the user.

Another metric is resource utilization. It is normal for cpu utilization and memory usage to go up to handle more traffic. Acceptable levels are 80% cpu utilization and not going into swap.

Design Tests

A naive way of load testing is to throw traffic at a single page, usually the front page of your website. You can measure throughput and response time with this approach but the problem is this isn't normal traffic. You probably don't have tens of thousands of users going to your front page and then not do anything else.

A better way is to figure out the actions of an average user on your website. For example, an average user on an ecommerce site will perform the following actions:

• Go to the front page
• Browse the list of products
• Search for a specific product
• Add products to the shopping cart
• Check out

Run Tests

Before you run your tests, make sure the test environment is as similar as possible to the production environment. You should also be able to measure the metrics you identified. This can be done by using a third-party service like New Relic or Skylight.

Choose a load testing tool. You have a number of options here. The main requirement is you can simulate the actions you listed above. Some of the open source load testing tools are JMeter, Tsung, and The Grinder.

Do not run the load testing tool on the same test environment. Use a different server so the resources it uses doesn't affect your tests.

Let's take a look at JMeter or specifically Ruby-JMeter, a Gem that lets you write JMeter test plans using Ruby. If you don't like writing XML, use Ruby-JMeter.

A test plan looks like this:

test do
  threads count: 10 do
    visit name: 'Example', url: 'http://example.com'
  end
end.jmx

Using our ecommerce example earlier, you can search for a product by submitting a form:

submit name: 'Submit Form', url: 'http://example.com',
  fill_in: {
    name: 'Turkey'
  }

As you can see, we can simulate the actions from the design phase using JMeter. We will send traffic to the front page and search for a product as well. Check the manual of the load testing tool of your choice on how to simulate all the actions of your average user. Do not skip some actions because your tool doesn't support it. You should choose a different tool instead of abandoning your plan.

Record Results

Whenever you run your tests, write down the number and size of your servers, throughput, response time, cpu utilization, and memory usage. Get a baseline before you make any changes to your setup or your application.

The baseline metrics are important because they tell you if the changes you make help or not. You would think that using more servers with bigger sizes always help but there are some cases they do the opposite or you only get minimal gains.

Iterate

After getting a baseline of metrics, you can add servers to your test environment and see how much additional traffic your site can handle. This will increase your throughput. This won't lower your response time and it can possibly increase it. Watch out for this metric.

There are other things you can try to increase throughput but adding servers is an easy choice, to begin with. This is called horizontal scaling and Rails handle this well. There are a few things to avoid like storing uploaded images to the local filesystem. Use S3 or EFS instead.

Add as many servers as you like until you reach your desired capacity or until you see issues on other parts of your stack like the database. Watch out for slow queries and the maximum number of connections allowed. As you add more servers and therefore more Ruby processes, you increase the number of connections to your database.

Load Testing Your Rails Application for Free

Engine Yard are the full-stack Ruby on Rails DevOps experts. We deploy and scale Rails applications on Amazon Web Services (AWS) and provide 24/7 Support. Do you want to know how many AWS servers you need to handle your traffic? Contact us and we'll help you load test your Rails application for free.