Question

A specific page for my ruby on rails website is slow.

To figure out what’s going on, I tried followed this guide in setting up this simple test on localhost:

class BrowsingTest < ActionDispatch::PerformanceTest
  def test_homepage    
    get '/slow_page'
  end
end

At this point my test database is empty, so I’d need to seed it with some data. After digging around with various things for a few hours I’m left a bit confused, and I’m not sure if I should:

1) Somehow copy the data from the production server and stick it into the test database(is there is an easy way to do this?)

OR

2) Generate many users and posts using test fixture .yml files

OR

3) Put code in seed.rb to generate users and posts. (I tried doing this, but for some reason the stuff I generate in this file disappears by the time my PerformanceTest gets run

4) I came across some gems like Factory Girl and Faker. I haven’t tried these yet, but from what I read it seems more for creating specific situations and states rather than generating thousands of users for performance testing.

I thought this would be a common scenario, and would love to get some advice from those who’ve done this. Thank you.

Answer 1

The best way to generate performance tests is to use real user data from your production server. If those are available to you, then definitely use them. The reason is that you want to optimize the performance of your webapp for the most common real user scenarios. Whatever scenarios you concoct that aren’t based on real user behavior are going to be less representative at best, or utterly useless at worst.

In practice, what you want to do is:

• Copy your production database and use that for your performance tests – this will ensure that whatever queries are running slow in production, due for example to big tables, missing indices, too many indices affecting update speed etc., do the same in your tests.
• Parse your webserver logs to figure out the number of concurrent requests on your slow pages at peak times, and generate the same kind of load (or higher – depends on your growth expectations) in your tests.
• You may want to look at services that offer real-life load approximations from a distributed network of servers. For example, take a look at Browser Mob