9ea3a8c67d
* Add dual booting logic to Gemfile This might be helpful for the Rails 6.0 upgrade project. * Add more than one gemfile to Travis' configuration We want to see how the application behaves with more than one Rails versions: - Gemfile -> Rails 5.2 - Gemfile.next -> Rails 6.0 This will help us figure out what needs to be addressed before migrating to Rails 6.0. If you want to read more about this technique (dual booting) you can check out this page: https://www.fastruby.io/blog/upgrade-rails/dual-boot/dual-boot-with-rails-6-0-beta.html * Fix joins * Upgrade Gemfile.next.lock * Make sure we're installing the correct versions of gems * Add Rails 6 notes * Update rubocop in Gemfile.next.lock * Fix organization spec * Fix page_views_spec * Add Rails 6 and run rails app:update * Remove some tricks * Remove Gemfile.next for now * Fix .content_type deprecation * Fix deprecation of .where.not NAND/NOR behavior * Fix deprecation of parameterized emails * Fix specs * Remove next flag for now * Fix spec (hopefully) * Add wait_for_javascript * Fix spec, thanks @maestromac! * Try without wait for javascript hack * Remove unnecessary bin/update * Remove file that snuck in the rebase * Update the vendored gems * Replace migrate+db:setup with db:prepare * Update vendored gems * Fix Gemfile.lock and update vendored stuff * Fix Gemfile.lock to be the same as master's minus the changes Co-authored-by: rhymes <rhymesete@gmail.com>
43 lines
1.7 KiB
Ruby
43 lines
1.7 KiB
Ruby
# Puma can serve each request in a thread from an internal thread pool.
|
|
# The `threads` method setting takes two numbers: a minimum and maximum.
|
|
# Any libraries that use thread pools should be configured to match
|
|
# the maximum value specified for Puma. Default is set to 5 threads for minimum
|
|
# and maximum; this matches the default thread size of Active Record.
|
|
#
|
|
threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
|
|
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 `environment` that Puma will run in.
|
|
#
|
|
environment ENV.fetch("RAILS_ENV") { "development" }
|
|
|
|
# Specifies the `pidfile` that Puma will use.
|
|
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }
|
|
|
|
# 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("WEB_CONCURRENCY") { 2 }
|
|
|
|
# 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!
|
|
|
|
# Allow puma to be restarted by `rails restart` command.
|
|
plugin :tmp_restart
|
|
|
|
on_worker_boot do
|
|
# Worker specific setup for Rails 4.1+
|
|
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
|
|
ActiveRecord::Base.establish_connection
|
|
end
|