This block is especially useful for connecting to different services as connections cannot be shared between multiple processes. The on_worker_boot block runs after a worker spawns, but before it begins to accept requests. Using on_worker_boot is no longer needed for Rails 5.2+ apps as forked connections will automatically re-connect. In the config above, these calls are used to establish Postgres connections for each worker process correctly. Preloading your application reduces the startup time of individual Puma worker processes and allows you to manage the external connections of each worker using the on_worker_boot calls. We recommend setting min to equal max.Įach Puma worker will be able to spawn up to the maximum number of threads you specify. This feature is not needed on Heroku as your application can consume all of the resources on a given dyno. The min threads setting allows your application to spin down resources when not under load. Puma allows you to configure your thread pool with a min and max setting, controlling the number of threads each Puma instance uses. These Ruby implementations do not have a GIL and will run all threads in parallel regardless of what is happening in them. JRuby and Rubinius also benefit from using Puma. Most Rails applications heavily use IO, so adding additional threads will allow Puma to process multiple threads, gaining you more throughput. IO operations such as database calls, interacting with the file system, or making external http calls will not lock the GIL. On MRI, there is a Global Interpreter Lock (GIL) that ensures only one thread can run at any time. Loosely speaking, workers consume more RAM and threads consume more CPU, and both offer more concurrency. This behavior allows Puma to provide additional concurrency for your web application. Puma can serve each request in a thread from an internal thread pool. Threads threads_count = Integer(ENV || 5) Monitor your application logs for R14 errors (memory quota exceeded) via one of our logging addons or Heroku logs. We recommend specifying this number in a config var to allow for faster application tuning. Your application may allow for more or less, depending on your specific memory footprint. 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.
#Number rack app 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)
