3

I swear that this was not an issue in the past and I can't pinpoint when I think this changed. In my local development environment if I make ANY changes to my models / controllers my server takes at least 20-30 seconds to reload and respond to requests. This is Rails 5.2.3 and Thin 1.7.2. I don't recall it ever being this slow before. FYI I have config.cache_classes = false already which is the obvious culprit.

Any ideas here?

Dan Tappin
  • 2,692
  • 3
  • 37
  • 77
  • Hope this helps: https://stackoverflow.com/questions/15317048/diagnosing-the-cause-of-slow-view-rendering – ARK Jan 29 '20 at 14:27
  • or this: https://stackoverflow.com/questions/16744279/rails-development-server-is-slow-and-takes-a-long-time-to-load-a-simple-page – ARK Jan 29 '20 at 14:28
  • If nothing helps, I suggest reading this article: http://brewhouse.io/blog/2015/04/27/fixing-a-slow-rails-development-server.html – ARK Jan 29 '20 at 14:29
  • The `config.assets.debug = false` looks most promising right now. Going to try these one at a time and see if I notice a change. – Dan Tappin Jan 29 '20 at 18:19
  • Any luck finding the culprit? I have the exact same issue, the server locks for 20 -30 seconds, using Rails 5.2.2 and Puma 3.12.1. Its actually faster for me to kill and reload puma then to wait for it to sort itself out after a code change... – Dalaigh88 Apr 01 '20 at 08:47
  • still not sure. Seem to be quiting everything and restarting the computer works best ‍♂️ – Dan Tappin Apr 01 '20 at 15:21

1 Answers1

0

I've been fighting with this issue for some time and I seem to have found two solutions worth trying. I run Rails 7.0.4 and Puma 6.0.

After debugging with rack-mini-profiler, I noticed that Thread::Mutex#synchronize was very slow. ~30 seconds. So I figured lowering the number of Puma threads might help. It improved but didn't completely solve the problem for me.

To run Puma single-threaded, I put the following in my Procfile:

RAILS_MIN_THREADS=0 RAILS_MAX_THREADS=1 bin/rails s -p 3000

The problem I was experiencing seems to be more directly related to this bug in Puma 6.0.0, as discussed here: https://github.com/ElMassimo/vite_ruby/issues/299 and https://github.com/jumpstart-pro/jumpstart-pro-rails/issues/475

Downgrading to 5.6.5 completely eliminated the issue, and I was able to return to multi-threaded Puma.

Carl Mercier
  • 1,231
  • 1
  • 12
  • 10