With a typical Rails memory footprint, you can expect to run 2-4 Puma worker processes on a free, hobby or standard-1x dyno. This behavior limits how many processes you can run in a single dyno. Omit this line from your config if you are using JRuby or Windows.Įach worker process used consumes additional memory.
Beyond the rack app trouble windows#
Multi-process mode does not work if you are using JRuby or Windows because the JVM and Windows do not support processes. Worker processes are isolated from one another at the OS level, therefore not needing to be thread-safe. In Puma terminology, these are referred to as worker processes (not to be confused with Heroku worker processes which run in their dynos). Puma forks multiple OS processes within each dyno to allow a Rails app to support multiple concurrent requests. To manually configure this value use heroku config:set WEB_CONCURRENCY.
The environment variable WEB_CONCURRENCY may be configured to a default value based on dyno size. You must also ensure that your Rails application has enough database connections available in the pool for all threads and workers. Threads_count = Integer(ENV || 5)Įnvironment ENV || 'development' For a simple Rails application, we recommend the following basic configuration: workers Integer(ENV || 2) ConfigĬreate a configuration file for Puma at config/puma.rb or at a path of your choosing. Make sure the Procfile is appropriately capitalized and checked into git. However, we recommend generating a config file: web: bundle exec puma -C config/puma.rb You can set most values inline: web: bundle exec puma -t 5:5 -p $ Set Puma as the server for your web process in the Procfile of your application. Adding Puma to your application Gemfileįirst, add Puma to your app’s Gemfile: gem 'puma' Always test your new deployments in a staging environment before you deploy to your production environment.
0 kommentar(er)
