Profiling

Available Tools

• gem detailed_benchmarks
• gem memory_profiler
• gem mini-profiler

Derailed Benchmarks Gem

https://github.com/schneems/derailed_benchmarks

To see gem memory usage

bundle exec derailed bundle:mem

Runtime memory usage for the app

bundle exec derailed bundle:objects

Convert to MB. Example crowdAI's gems use 105.59MB for gems alone.

https://github.com/presidentbeef/brakeman

Do I have a memory leak?

Using the derailed_benchmarks gem, run increasing numbers of tests. If the memory usage is not stable there is a leak.

TEST_COUNT=5000 bundle exec derailed exec perf:mem_over_time
TEST_COUNT=10_000 bundle exec derailed exec perf:mem_over_time
TEST_COUNT=20_000 bundle exec derailed exec perf:mem_over_time

Puma

Puma is a multithreaded server and MRI is single threaded. Puma will work best with Rubinius or JRuby.

• There is a gem configuring a default plugin, but the contents can be easily added to the initializer https://github.com/puma/puma-heroku/blob/master/lib/puma/plugin/heroku.rb

Because MRI doesn't have "real threads", ideally there would be at least one worker for each CPU core. Heroku 1x, 2x, and Performance-M dynos each have 8 cores. Performance-L dynos have 2 cores.

It's often not possible to have a worker per core, because of memory constraints. For example, a medium to large rails app on a Heroku 2x dyno will take up 300-550 megs, which alows for only running 1-3 workers.

Some references

https://github.com/puma/puma-heroku

http://julianee.com/rails-sidekiq-and-heroku/

http://stackoverflow.com/questions/8821864/config-assets-compile-true-in-rails-production-why-not

https://github.com/puma/puma-heroku/issues/4