Setting up Puma and Rails on Heroku

puma_rails_heroku.rb

# Gemfile
gem "puma"

# Procfile
web: bundle exec puma -p $PORT -e $RACK_ENV -C config/puma.rb

# add to config block config/environments/production.rb
config.threadsafe!

# get rid of NewRelic after_fork code, if you were doing this:
# http://support.newrelic.com/kb/troubleshooting/unicorn-no-data
# and get rid of config/unicorn.rb if you were using that

# config/puma.rb
require "active_record"
cwd = File.dirname(__FILE__)+"/.."
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(ENV["DATABASE_URL"] || YAML.load_file("#{cwd}/config/database.yml")[ENV["RACK_ENV"]])
ActiveRecord::Base.verify_active_connections!

# if you use NewRelic, set your NEWRELIC_DISPATCHER environment variable on heroku, per
# https://github.com/puma/puma/issues/128 - may not be needed for future releases of Puma

heroku config:add NEWRELIC_DISPATCHER=Puma

Why do you need the config/puma.rb?

Why do you need the config/puma.rb?

Hey Mike, what's your reasoning behind disconnecting and reconnecting? Thanks in advance! Thomas

Hey Mike, what's your reasoning behind disconnecting and reconnecting? Thanks in advance! Thomas

@juniorz @thomasklemm You can't pass the same connection across a fork, need puma to re/connect on fork.

@juniorz @thomasklemm You can't pass the same connection across a fork, need puma to re/connect on fork.

I don't think Puma forks at all, it uses thread. Also, the config file will run when puma reads the configuration file and not after creating a thread (or a fork).

I don't think Puma forks at all, it uses thread. Also, the config file will run when puma reads the configuration file and not after creating a thread (or a fork).

@divoxx is right. According to Puma's README:

Puma then serves the request in a thread from an internal thread pool (which you can control). This allows Puma to provide real concurrency for your web application!

There's no need to use that config/puma.rb config file. And AFAIK, on Rails 4 (and maybe also on 3.2), if an ENV['DATABASE_URL'], it won't need config/database.yml.

Curious about what a Puma config file is about? Check https://github.com/puma/puma/tree/master/examples for some examples.

@divoxx is right. According to Puma's README:

Puma then serves the request in a thread from an internal thread pool (which you can control). This allows Puma to provide real concurrency for your web application!

There's no need to use that config/puma.rb config file. And AFAIK, on Rails 4 (and maybe also on 3.2), if an ENV['DATABASE_URL'], it won't need config/database.yml.

Curious about what a Puma config file is about? Check https://github.com/puma/puma/tree/master/examples for some examples.

heroku config:add NEWRELIC_DISPATCHER=Puma will make New Relic think ALL Heroku processes are Pumas, including workers and one-off heroku run rails c.

I know Puma 2 makes this setting unnecessary, but it's still in beta so I'm on the latest 1x (1.6.3).

Does anybody know how to detect what Heroku PS type was invoked? Or some other way to tell if I'm running on a web dyno or not? I figure I can use that knowledge in an initializer to only set ENV[NEWRELIC_DISPATCHER]=Puma for web dynos.

heroku config:add NEWRELIC_DISPATCHER=Puma will make New Relic think ALL Heroku processes are Pumas, including workers and one-off heroku run rails c.

I know Puma 2 makes this setting unnecessary, but it's still in beta so I'm on the latest 1x (1.6.3).

Does anybody know how to detect what Heroku PS type was invoked? Or some other way to tell if I'm running on a web dyno or not? I figure I can use that knowledge in an initializer to only set ENV[NEWRELIC_DISPATCHER]=Puma for web dynos.

An alternative approach that helps increase AR's connection pool size on Heroku has been published in the Heroku dev center.

An alternative approach that helps increase AR's connection pool size on Heroku has been published in the Heroku dev center.

config.threadsafe! is deprecated for rails 4:

"Rails applications behave by default as thread safe in production as long as config.cache_classes and config.eager_load are set to true."

config.threadsafe! is deprecated for rails 4:

"Rails applications behave by default as thread safe in production as long as config.cache_classes and config.eager_load are set to true."

ActiveRecord::Base.verify_active_connections! is also deprecated, and should be removed.

ActiveRecord::Base.verify_active_connections! is also deprecated, and should be removed.

yeah you don't need a puma.rb file. That was vestigial from when I was on unicorn, and I thought had read somewhere that puma needed it to be able to restart cleanly

yeah you don't need a puma.rb file. That was vestigial from when I was on unicorn, and I thought had read somewhere that puma needed it to be able to restart cleanly

here's the relevant info for the new cool way to do it https://devcenter.heroku.com/articles/concurrency-and-database-connections#connection-pool

here's the relevant info for the new cool way to do it https://devcenter.heroku.com/articles/concurrency-and-database-connections#connection-pool