puma.rb

# frozen_string_literal: true

# This configuration file will be evaluated by Puma. The top-level
# methods that are invoked here are part of Puma's configuration DSL.
# For more information about methods provided by the DSL, see
# https://puma.io/puma/Puma/DSL.html.

# Puma starts a configurable number of processes (workers) and each
# process serves each request in a thread from an internal thread pool.
#
# The ideal number of threads per worker depends both on how much time
# the application spends waiting for IO operations and on how much you
# wish to to prioritize throughput over latency.
#
# As a rule of thumb, increasing the number of threads will increase how
# much traffic a given process can handle (throughput), but due to
# CRuby's Global VM Lock (GVL) it has diminishing returns and will
# degrade the response time (latency) of the application.
#
# The default is set to 3 threads as it's deemed a decent compromise
# between throughput and latency for the average Rails application.
#
# Any libraries that use a connection pool or another resource pool
# should be configured to provide at least as many connections as the
# number of threads. This includes Active Record's `pool` parameter in
# `database.yml`.
threads_count = ENV.fetch('RAILS_MAX_THREADS', 3)
threads threads_count, threads_count

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
port ENV.fetch('PORT', 3000)

# Specifies the number of `workers` to boot in clustered mode. Workers
# are forked webserver processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
#
workers ENV.fetch('WORKERS', 0)

# Specify the PID file. Defaults to tmp/pids/server.pid in development.
# In other environments, only set the PID file if requested.
pidfile ENV['PIDFILE'] if ENV['PIDFILE']

# Use the `preload_app!` method when specifying a `workers` number. This
# directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
#
preload_app!

before_fork do
  ActiveRecord::Base.connection.disconnect!
  Msgr.client.stop if defined?(Msgr)
end

on_worker_boot do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::Base.establish_connection
  end
end

# Allow puma to be restarted by `bin/rails restart` command.
plugin :tmp_restart