Switch to the Puma web server

WEBrick is not suited to production environments. It is single threaded
and single process which means that if two requests come in at the same
time, the second must wait for the first to finish. Puma, on the other
hand, is multi-threaded and can spawn multiple workers

Author: HashNotAdam

Gemfile

@@ -3,6 +3,7 @@
 source 'https://rubygems.org'
 ruby '2.3.4'
 
+gem 'puma'
 gem 'rack-rewrite'
 gem 'rails', '~> 5.0.5'
 
@@ -81,5 +82,6 @@ group :test do
 end
 
 group :production do
+  gem 'rack-timeout'
   gem 'rails_12factor', '0.0.3'
 end

Gemfile.lock

@@ -263,6 +263,7 @@ GEM
     pry-rails (0.3.6)
       pry (>= 0.10.4)
     public_suffix (2.0.5)
+    puma (3.10.0)
     pusher (1.1.0)
       httpclient (~> 2.7)
       multi_json (~> 1.0)
@@ -274,6 +275,7 @@ GEM
     rack-rewrite (1.5.1)
     rack-test (0.6.3)
       rack (>= 1.0)
+    rack-timeout (0.4.2)
     railroady (1.4.2)
     rails (5.0.5)
       actioncable (= 5.0.5)
@@ -494,8 +496,10 @@ DEPENDENCIES
   omniauth-google-oauth2 (~> 0.5.2)
   pg (= 0.18.4)
   pry-rails
+  puma
   pusher (= 1.1.0)
   rack-rewrite
+  rack-timeout
   railroady (= 1.4.2)
   rails (~> 5.0.5)
   rails-controller-testing
@@ -523,4 +527,4 @@ RUBY VERSION
    ruby 2.3.4p112
 
 BUNDLED WITH
-   1.15.3
+   1.15.4

Procfile

@@ -1,2 +1,2 @@
 # Procfile
-web: bundle exec rails s -b 0.0.0.0 -p $PORT
+web: bundle exec puma -C config/puma.rb

config/initializers/timeout.rb

@@ -0,0 +1,11 @@
+# frozen_string_literal: true
+
+# There is no request timeout mechanism inside of Puma. The Heroku router will
+# timeout all requests that exceed 30 seconds. Although an error will be
+# returned back to the client, Puma will continue to work on the request as
+# there is no way for the router to notify Puma that the request terminated
+# early. To avoid clogging processing ability, Rack::Timeout terminates long
+# running requests.
+if defined?(Rack::Timeout)
+  Rack::Timeout.timeout = 20 # seconds
+end

config/puma.rb

@@ -1,27 +1,29 @@
+# frozen_string_literal: true
+
+# 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 }
+
 # 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 }.to_i
+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 }
+port ENV.fetch('PORT') { 3000 }
 
 # Specifies the `environment` that Puma will run in.
 #
-environment ENV.fetch("RAILS_ENV") { "development" }
-
-# 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 }
+environment ENV.fetch('RACK_ENV') { 'development' }
 
 # Use the `preload_app!` method when specifying a `workers` number.
 # This directive tells Puma to first boot the application and load code
@@ -30,7 +32,7 @@
 # you need to make sure to reconnect any threads in the `on_worker_boot`
 # block.
 #
-# preload_app!
+preload_app!
 
 # The code in the `on_worker_boot` will be called if you are using
 # clustered mode by specifying a number of `workers`. After each worker
@@ -39,9 +41,11 @@
 # or connections that may have been created at application boot, Ruby
 # cannot share connections between processes.
 #
-# on_worker_boot do
-#   ActiveRecord::Base.establish_connection if defined?(ActiveRecord)
-# end
+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
 
 # Allow puma to be restarted by `rails restart` command.
-plugin :tmp_restart
+plugin :tmp_restart