Rails Server Extremely Slow in Development - ruby-on-rails

I've got a rails 5 application that is very slow after I boot the server or change a .rb file. Below is my cli output after I booted the server with rails server and loaded a simple page. Also, if I change a model, controller or helper, the server takes about the same time to respond to the next request. After the request is loaded, the pages load normally but that first request after each change can take 30 seconds which adds up quite fast. I have tried setting the following configs in `development (similar questions suggested these changes). Also, I have this development server running on a digital ocean droplet with 4GB of memory.
config.assets.debug = false
config.assets.digest = false
My output:
rails server
=> Booting Puma
=> Rails 5.2.2 application starting in development
=> Run rails server -h for more startup options
Puma starting in single mode...
* Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Started GET "/treadmill-parts-model-select" for 98.251.169.224 at 2019-04-03
11:51:29 +0000
Cannot render console from 98.251.169.224! Allowed networks: 127.0.0.1, ::1,
127.0.0.0/127.255.255.255
(2.1ms) SET NAMES utf8, ##SESSION.sql_mode = CONCAT(CONCAT(##sql_mode,
',STRICT_ALL_TABLES'), ',NO_AUTO_VALUE_ON_ZERO'),
##SESSION.sql_auto_is_null = 0, ##SESSION.wait_timeout = 2147483
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
(2.4ms) SELECT 'schema_migrations'.'version' FROM 'schema_migrations' ORDER
BY 'schema_migrations'.'version' ASC
↳ /usr/local/rvm/gems/ruby-2.5.3/gems/activerecord-
5.2.2/lib/active_record/log_subscriber.rb:98
Processing by SearchController#treadmill_model_search as HTML
Rendering search/treadmill_model_search.html.erb within layouts/application
Product Load (113.8ms) SELECT DISTINCT 'products'.'brand' FROM 'products' WHERE 'products'.'product_type' = 'Treadmill' ORDER BY 'products'.'brand' ASC
↳ app/views/search/treadmill_model_search.html.erb:22
Rendered search/treadmill_model_search.html.erb within layouts/application (167.6ms)
Rendered layouts/_header.html.erb (5.8ms)
Rendered layouts/_flash_messages.html.erb (1.1ms)
Rendered layouts/_footer.html.erb (0.5ms)
Completed 200 OK in 18746ms (Views: 18565.0ms | ActiveRecord: 124.7ms)`

Looks like every time your rails server detects a page change it checks to see if their is a migration pending, which will take some time.
#config/environments/development.rb
config.active_record.migration_error = false
could help with that check.
In the development environment your application's code is reloaded on every request. This slows down response time but is perfect for development since you don't have to restart the web server when you make code changes.
As with larger projects you will want to stop rails from pre-loading all the code which isn't needed especially if you are only working on a portion of your project anyways. Also in the environment
#config/environments/development.rb
# Do not eager load code on boot.
config.eager_load = false
You can read more on these environment config settings here
Though the 4GB of memory seems like a red flag if you aren't working on a massive project... might need to look into your initializes and what all your project is loading up on boot.

Related

Cron doesn't run Rails Puma server automatically in Ubuntu

I deployed a Rails application in Digital Ocean Ubuntu Server using Capistrano. For some reason the puma server suddenly stops. I'm not sure what's the reason.
That's why I created a script /home/deploy/startup-script.sh
the script contains the commands to startup the Rails application in daemon
#!/bin/bash
echo "Running Puma Server"
touch hello.txt
cd /srv/www/apps/app/current
bundle exec puma -C /srv/www/apps/app/shared/puma.rb --daemon
then I run this script every minute using Cron.
My crontab -e contains
* * * * * ./startup-script.sh
After 1 minute I noticed that it created a hello.txt file but my puma server is not running.
But when I run it manually using ./startup-script.sh it will run the server.
puma_error.log
Puma starting in single mode...
* Version 4.3.1 (ruby 2.6.0-p0), codename: Mysterious Traveller
* Min threads: 0, max threads: 8
* Environment: production
* Daemonizing...
=== puma startup: 2020-09-21 05:16:28 +0000 ===
=== puma startup: 2020-09-21 05:17:39 +0000 ===
* Listening on tcp://0.0.0.0:9292
=== puma startup: 2020-09-21 06:11:35 +0000 ===
- Gracefully stopping, waiting for requests to finish
=== puma shutdown: 2020-09-21 06:11:35 +0000 ===
production.log
Item Load (0.3ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 208], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 4], ["LIMIT", 1]]
Item Load (0.3ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 215], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 4], ["LIMIT", 1]]
Item Load (0.2ms) SELECT "items".* FROM "items" WHERE "items"."id" = $1 LIMIT $2 [["id", 198], ["LIMIT", 1]]
CACHE Unit Load (0.0ms) SELECT "units".* FROM "units" WHERE "units"."id" = $1 LIMIT $2 [["id", 10], ["LIMIT", 1]]
Rendering text template
Rendered text template (0.0ms)
Sent data Delivery Receipt 12-2020-001.pdf (0.5ms)
Completed 200 OK in 4326ms (Views: 0.3ms | ActiveRecord: 37.4ms)
puma_access.log
=== puma startup: 2020-12-01 01:07:13 +0000 ===
When starting the startup-script.sh script I'm getting this
Running Puma Server
Puma starting in single mode...
* Version 4.3.1 (ruby 2.6.0-p0), codename: Mysterious Traveller
* Min threads: 0, max threads: 8
* Environment: production
* Daemonizing...
My droplet is still running but the puma running on port 9292 disappears when crashes, so I suspect this is puma error.
Depending on your version of Puma, the --daemon option might be deprecated. Use & instead:
bundle exec puma -C /srv/www/apps/app/shared/puma.rb &
However, your issue isn't with Cron or with Puma. Puma doesn't exit on its own unless something else happens. I recommend that you have a look at the error logs and figure out the real issue.
Edit:
To answer your comment:
I recommend that you update Puma to version the latest 4.x release (currently 4.3.6). If you can switch to Puma 5.x (currently 5.1) that would be even better. There are bug fixes and improvements all the time. Maybe your issue is related to a solved bug.
If you update to the 5.x version family, you will need to replace the --daemon with a & as mentioned above.
Side Note:
However, I still believe there's an error report you didn't notice of that your toolset failed to log.
I don't know if you looked at the Capistrano logs as well as the Rails / Puma logs and the DigitalOcean server logs.
If you're running Puma with --debug, some Puma messages must appear in the log.
I don't think puma just stops by itself. Maybe it is not running properly as a daemon? I would suggest to figure out what's going on.
That being said, in order to ensure that a certain daemon is always up and running you should use a tool like supervisord: http://supervisord.org/
A cronjob is not the right tool.

rails 5 hide production output unique request identifier

A unique identifier is showing before every request output (dev server)
Here an example:
$ rails s
=> Booting Puma
=> Rails 5.0.3 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.10.0 (ruby 2.4.1-p111), codename: Russell's Teapot
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Started GET "/plans" for 127.0.0.1 at 2017-10-17 17:06:48 -0300
[5664e61d-73e6-4ce3-af27-d82aa04abebd] ActiveRecord::SchemaMigration Load (0.6ms) SELECT "schema_migrations".* FROM "schema_migrations"
[5664e61d-73e6-4ce3-af27-d82aa04abebd] DEPRECATION WARNING: before_filter is deprecated and will be removed in Rails 5.1. Use before_action instead. (called from <class:ApplicationController> at /Users/tdonatti/Sites/rails/vmsapi/app/controllers/application_controller.rb:10)
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Processing by PlansController#index as HTML
[5664e61d-73e6-4ce3-af27-d82aa04abebd] User Load (0.4ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2 [["id", 9],
["LIMIT", 1]]
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Plan Load (0.4ms) SELECT "plans"."id", "plans"."title", "plans"."nod", "plans"."price", "plans"."status" FROM "plans"
[5664e61d-73e6-4ce3-af27-d82aa04abebd] Completed 200 OK in 38ms (Views: 9.4ms | ActiveRecord: 7.4ms)
I want to hide this identifier [5664e61d-73e6-4ce3-af27-d82aa04abebd]
I am not sure why and how it shows up but make the output extremely noisy and difficult to track.
In your config file you must have log_tags set to something like
config.log_tags = [ :uuid ]
Remove that and you should be good to go.
Log tags are beneficial for debugging - give this a read when you have time.

Rails extremely slow on simple static render

I'm relatively new to Rails, but decided to develop my new project on this platform. I'm using new Rails 4 framework based on Ruby 2.0 and Unicorn as application server served through Nginx.
After some initial development I deployed my application to Amazon EC2 small server, and was literally shocked by the slow performance, testing it with simple ab utility. Giving you more details:
unicorn config file:
# config/unicorn.rb
env = ENV["RAILS_ENV"] || "development"
worker_processes 1
listen 8080, :backlog => 64
preload_app true
timeout 30
pid "/tmp/unicorn.mysite.pid"
if env == "production"
working_directory "/mypath/current"
user 'ubuntu', 'ubuntu'
shared_path = "/mypath/shared"
stderr_path "#{shared_path}/log/unicorn.stderr.log"
stdout_path "#{shared_path}/log/unicorn.stdout.log"
end
before_fork do |server, worker|
if defined?(ActiveRecord::Base)
ActiveRecord::Base.connection.disconnect!
end
old_pid = "/tmp/unicorn.mysite.pid.oldbin"
if File.exists?(old_pid) && server.pid != old_pid
begin
Process.kill("QUIT", File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH
end
end
end
after_fork do |server, worker|
if defined?(ActiveRecord::Base)
ActiveRecord::Base.establish_connection
end
end
routes.rb:
root to: "home#index"
home_controller.rb:
def index
render "index", layout: false
end
and index.html.erb is just mostly static 3kb file
There are no DB queries, Unicorn running in production mode, partials cache enabled in Rails.
ab -n 1000 -c 100 http://myinstance.amazon.com/ returns like 30-40 requests/per second performance, and average 3-4 seconds response time with 1 unicorn's worker(remember I'm using small 1cpu instance), and even less when increased to four. Strange enough when I tried to test the application on amazon's medium instance, it didnt improve the performance, giving a hint that it's probably limited by disk io. Well, when I replicated the same simple application on PHP and node.js stacks, that I used before, significantly better performance(more requests per second served with much shorter response times) comparing to the above mentioned Rails.
Is it normal for a Rails application? Any hints how to improve performance? Maybe some configuration tweaks? I tried to search, but I see mostly general information about Rails code improvements that do not apply here due to oversimplified example.
UPDATE #1
I include pieces of production.log on request, they vary from:
I, [2013-07-20T13:21:44.830189 #1852] INFO -- : Started GET "/" for xx.xx.xx.xx at 2013-07-20 13:21:44 +0000
I, [2013-07-20T13:21:44.831420 #1852] INFO -- : Processing by HomeController#index as */*
I, [2013-07-20T13:21:44.832519 #1852] INFO -- : Rendered layouts/_head.html.erb (0.5ms)
I, [2013-07-20T13:21:44.834213 #1852] INFO -- : Rendered layouts/_header.html.erb (1.5ms)
I, [2013-07-20T13:21:44.834966 #1852] INFO -- : Rendered layouts/_footer.html.erb (0.0ms)
I, [2013-07-20T13:21:44.835143 #1852] INFO -- : Rendered home/index.html.erb (3.2ms)
I, [2013-07-20T13:21:44.835356 #1852] INFO -- : Completed 200 OK in 4ms (Views: 3.5ms | ActiveRecord: 0.0ms)
to:
I, [2013-07-20T13:21:44.689225 #1852] INFO -- : Started GET "/" for xx.xx.xx.xx at 2013-07-20 13:21:44 +0000
I, [2013-07-20T13:21:44.690629 #1852] INFO -- : Processing by HomeController#index as */*
I, [2013-07-20T13:21:44.716144 #1852] INFO -- : Rendered layouts/_head.html.erb (24.7ms)
I, [2013-07-20T13:21:44.718191 #1852] INFO -- : Rendered layouts/_header.html.erb (1.7ms)
I, [2013-07-20T13:21:44.718919 #1852] INFO -- : Rendered layouts/_footer.html.erb (0.0ms)
I, [2013-07-20T13:21:44.719042 #1852] INFO -- : Rendered home/index.html.erb (27.7ms)
I, [2013-07-20T13:21:44.719280 #1852] INFO -- : Completed 200 OK in 28ms (Views: 28.2ms | ActiveRecord: 0.0ms)
UPDATE #2
I tried to make 10000 consequent requests and server simply timed out in the middle
ab -n 10000 -c 100 http://myinstance.amazon.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking myinstance.amazon.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
apr_socket_recv: Connection timed out (110)
Total of 3457 requests completed
It seems that it is quite expected result. You compare 3 different things: full-featured framework (Rails), platform (Node.js) and language (PHP).
Let's see how we split the response time:
[total time] = [web server processing time] + [framework infrastructure time]
+ [language interpreter time] + [your app logic time]
Of course, in case if your application will do nothing, the last component can be neglected.
When you run PHP or Node.js application there remain only 2 components in the sum: [web server processing time] + [language interpreter time], so it can handle requests very fast. Rails adds here the 3d component [framework infrastructure time].
If your application will start to do something more advanced then time spent in framework and webserver can have less impact on the total time (relatively). Though JavaScript will outperform Ruby nevertheless.
To be more objective you'd better add something on top of Node.js (like Express.js) or PHP (like Yii or Zend Framework). Or use something more lightweight instead of Rails to process small request much faster (e.g. Sinatra)

Rails 3.1rc4 asset pipeline broke after Ruby update? How to re-activate/configure it?

Somehow this is related but I'm not sure how/why?
Just upgraded from Ruby 1.9.2-p180 to 1.9.2-p290 via RVM's rvm upgrade command...and now my asset pipeline is 'broken'.
During rvm upgrade ... I noticed a bunch of errors for each gemset along lines of:
ERROR: Error running 'rvm gemset pristine' under ,
please read /Users/meltemi/.rvm/log//gemset.pristine.log
I let upgrade continue as there was not much interesting in the gemset.pristine.log... besides, /Users/meltemi/.rvm/log//gemset.pristine.log doesn't (can't?) exist in that exact path? two consecutive '//' in a pathname? Anyway...
Testing a small app and though it launches and appears to run it is not loading any assets (images, css, etc.). Development log has many Not Found errors (see below) about these missing assets even though they exist within app/assets/images and app/assets/stylesheets, etc... ?
Anyone know what's happening here? Seems like pipeline has broken down somehow... As if Rails no longer knows to look for assets in app/assets, perhaps? How can I test/verify/fix/re-activate this 'pipeline'?
$ rails s
=> Booting WEBrick
=> Rails 3.1.0.rc4 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-07-25 23:11:38] INFO WEBrick 1.3.1
[2011-07-25 23:11:38] INFO ruby 1.9.2 (2011-07-09) [x86_64-darwin10.8.0]
[2011-07-25 23:11:38] INFO WEBrick::HTTPServer#start: pid=74881 port=3000
Started GET "/" for 127.0.0.1 at 2011-07-25 23:11:43 -0700
Processing by PostsController#index as HTML
Post Load (0.2ms) SELECT "posts".* FROM "posts" ORDER BY posts.created_at DESC
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.3ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 6
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 5
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 4
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 2
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Photo Load (0.2ms) SELECT "photos".* FROM "photos" WHERE "photos"."post_id" = 1
Rendered posts/index.html.haml within layouts/application (3016.4ms)
Rendered layouts/_header.html.haml (9.7ms)
Completed 200 OK in 3143ms (Views: 3138.2ms | ActiveRecord: 2.9ms)
Started GET "/assets/application.css" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.css - 404 Not Found (1ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.css"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
Started GET "/assets/application.js" for 127.0.0.1 at 2011-07-25 23:11:47 -0700
Served asset /application.js - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/application.js"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (0.8ms)
Started GET "/assets/racer-outline.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /racer-outline.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/racer-outline.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (3.2ms)
Started GET "/assets/ray.png" for 127.0.0.1 at 2011-07-25 23:11:48 -0700
Served asset /pogo.png - 404 Not Found (0ms)
ActionController::RoutingError (No route matches [GET] "/assets/ray.png"):
Rendered /Users/meltemi/.rvm/gems/ruby-1.9.2-p290#rails3/gems/actionpack-3.1.0.rc4/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (1.2ms)
It seems that version 2.0.0.beta.11 of sprockets broke the assets pipeline. Putting
gem 'sprockets', '= 2.0.0.beta.10'
into your Gemfile seems to fix the problem (it worked for me). Rails seems to automatically use the most recent version of the beta for whatever reason so if you just started your project recently or updated all your gems it probably broke it.
Note that this info isn't mine originally, I got the fix from http://groups.google.com/group/rubyonrails-core/browse_thread/thread/59d8c7813b4d1bbe?pli=1
He explains the problem for ver. 2.0.0.beta.11 but I was using ver. 2.0.0.beta.12 with the same results so it seems that they haven't fixed it yet.
EDIT: It seems that upgrading your rails to 3.1.rc5 also fixes the problem
I ended up just blowing out the whole problematic gemset and starting anew. Lesson learned:
Don't trust rvm upgrade. Install the new Ruby w/in RVM. Then manually rebuild (or bundle install) your gemsets.

Heroku: see params and sql activity in logs?

When i view my heroku logs on the server (with heroku logs --tail --app myapp) i see something like this:
2011-06-21T14:09:25+00:00 app[web.1]: Started PUT "/reports/19.xml" for 77.89.149.137 at 2011-06-21 07:09:25 -0700
2011-06-21T14:09:25+00:00 heroku[router]: PUT myapp.heroku.com/reports/19.xml dyno=web.1 queue=0 wait=0ms service=7ms status=401 bytes=28
2011-06-21T14:09:26+00:00 heroku[nginx]: PUT /reports/19.xml HTTP/1.1 | 77.89.149.137 | 656 | http | 401
While in my local log i'd see something like this:
Started PUT "/reports/19" for 127.0.0.1 at 2011-06-21 15:27:01 +0100
Processing by ReportsController#update as XML
Parameters: {"report"=>{"workflow_status"=>"3"}, "id"=>"19"}
Person Load (0.9ms) SELECT "people".* FROM "people" WHERE "people"."email" = 'madeupemai#lkklj.com' LIMIT 1
Report Load (0.4ms) SELECT "reports".* FROM "reports" WHERE "reports"."id" = 19 LIMIT 1
DEPRECATION WARNING: Object#returning has been deprecated in favor of Object#tap. (called from update_report at /home/max/work/rails_apps/flamingo_container/flamingo/vendor/plugins/resource_this/lib/resource_this.rb:135)
Creating scope :open. Overwriting existing method Task.open.
Task Load (2.0ms) SELECT "tasks".* FROM "tasks" WHERE "tasks"."id" = 14 LIMIT 1
Completed 200 OK in 1648ms (Views: 568.2ms | ActiveRecord: 3.2ms)
Ie with a lot more information, particularly the params, info from the router, generated sql, any templates rendered etc etc.
Does anyone know how i can get my heroku log to be as verbose as my development one? I've done the following already:
1) Set the log level in the relevant (rails 3) environment file:
config.log_level = :debug
2) Told heroku to use a different logger level, as described on http://devcenter.heroku.com/articles/logging
heroku config:add LOG_LEVEL=DEBUG --app myapp #from CLI
Neither has made any difference...any ideas anyone?
thanks, max
You're essentially wanting to show the SQL / params output in the Heroku logs. You can do this by adding the line shown below to the config block within your production.rb file:
MyAppNameHere::Application.configure do
# add this line
config.logger = Logger.new(STDOUT)
end
By the way, setting the log level to debug just means that Rails.logger.debug will output to the logs when you're on Heroku
In your production.rb add config.log_level = :debug and redeploy. That will give you the same logs as development mode :)
The detailed log you want is generated by the function start_processing in log_subscriber.rb.
action_controller/log_subscriber.rb:
def start_processing(event)
payload = event.payload
params = payload[:params].except(*INTERNAL_PARAMS)
info " Processing by #{payload[:controller]}##{payload[:action]} as #{payload[:formats].first.to_s.upcase}"
info " Parameters: #{params.inspect}" unless params.empty?
end
I checked with rails 3.0.4 in development and production environment. In both environments, we have the detailed logs.
This is an info level log. That's why the debug log level is not changing the output.
I installed the plugin used by heroku rails_log_stdout (Heroku logging) but I still have the desired output.
Right now, I can't test with heroku to find out why you don't have all the logs.
In the heroku example (see Heroku logging, section log retrieval), we don't see the "Processing" and "Parameters" lines. I think that either this method is not called when the app is running on heroku (it is somehow disabled) or heroku skips logs starting with whitespaces. Could you try to log messages starting with whitespaces and see if heroku is showing them?
Rails doesn't generate those logs when in production mode. http://groups.google.com/group/heroku/browse_thread/thread/d778fafedc9a378a
The real problem is actually due to the way Heroku works in conjunction with rails. The right way to solve this is to add: gem 'rails_12factor', group: :production
See https://devcenter.heroku.com/articles/rails-integration-gems for more info on the matter
Looks like the puma server doesn't play well with Heroku. In my project, I tried everything, but it still wouldn't log. I then replaced Puma with Unicorn, and bam, full logs are being shown.

Resources