Go faster, off the Rails – Benchmarks for your whole Rails app. A series of things you can use to benchmark a Rails or Ruby app.


1. Install

Put this in your gemfile:

gem 'derailed_benchmarks', group: :development

Then run

$ bundle install.

While executing your commands you may need to use bundle exec before typing the command.

To use all profiling methods available also add:

gem 'stackprof', group: :development

2. Use

2.1 Static Benchmarking

This section covers how to get memory information from your Gemfile without having to boot your app.

All commands in this section will begin with $ derailed bundle:

For more information on the relationship between memory and performance please read/watch How Ruby Uses Memory.

2.1.1 Memory used at Require time

Each gem you add to your project can increase your memory at boot. You can get visibility into the total memory used by each gem in your Gemfile by running:

$ bundle exec derailed bundle:mem

This will load each of your gems in your Gemfile and see how much memory they consume when they are required. For example if you’re using the mail gem. The output might look like this

$ bundle exec derailed bundle:mem
TOP: 54.1836 MiB
  mail: 18.9688 MiB
    mime/types: 17.4453 MiB
    mail/field: 0.4023 MiB
    mail/message: 0.3906 MiB
  action_view/view_paths: 0.4453 MiB
    action_view/base: 0.4336 MiB

2.1.2 Objects created at Require time

To get more info about the objects, using memory_profiler, created when your dependencies are required you can run:

$ bundle exec derailed bundle:objects

This will output detailed information about objects created while your dependencies are loaded

Measuring objects created by gems in groups [:default, “production”]

Total allocated 433895
Total retained 100556

allocated memory by gem
  24369241  activesupport-4.2.1
  15560550  mime-types-2.4.3
   8103432  json-1.8.2

2.2 Running Derailed Exec

You can run commands against your app by running $ derailed exec. There are sections on setting up Rack and using authenticated requests below. You can see what commands are available by running:

$ bundle exec derailed exec --help
  $ derailed exec perf:allocated_objects  # outputs allocated object diff after app is called TEST_COUNT times
  $ derailed exec perf:gc  # outputs GC::Profiler.report data while app is called TEST_COUNT times
  $ derailed exec perf:ips  # iterations per second
  $ derailed exec perf:mem  # show memory usage caused by invoking require per gem
  $ derailed exec perf:objects  # profiles ruby allocation
  $ derailed exec perf:mem_over_time  # outputs memory usage over time
  $ derailed exec perf:test  # hits the url TEST_COUNT times

3. Environment Variables

All the tasks accept configuration in the form of environment variables.

3.1 Hitting a different endpoint with PATH_TO_HIT

By default tasks will hit your homepage /. If you want to hit a different url use PATH_TO_HIT for example if you wanted to go to users/new you can execute:

$ PATH_TO_HIT=/users/new bundle exec derailed exec perf:mem

This method accepts a full uri. For example, allowing you to hit a subdomain endpoint:

$ PATH_TO_HIT=http://subdomain.lvh.me:3000/users/new bundle exec derailed exec perf:mem

Beware that you cannot combine a full uri with USE_SERVER.


schneems/derailed_benchmarks: Go faster, off the Rails – Benchmarks for your whole Rails app

Debugging a Memory Leak on Heroku | via @codeship

Profile your gem memory usage with Derailed


Leave a Reply

Your email address will not be published. Required fields are marked *