Put this in your gemfile:
gem 'derailed_benchmarks', group: :development
$ 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.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