I am trying to upgrade rails app from v3 to v4. In v3, the server start time is less than a minute. but in v4, it is taking more than 30 mins. In logs, i can see that for each server start,
1/10 preloading assets...
2/10 preloading assets...
.
.
10/10 preloading aseets...
done
is being logged and this is the part taking up 99% of the time. I believe assets are being compiled every time while loading the classes. could someone please let me know which config is causing this ?
I have tried most of the suggested solutions related to asset config in stackoverflow but doesnt seem to get resolved.
current config:
config.cache_classes = false
config.eager_load = false
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
config.reload_classes_only_on_change = true
config.assets.digest = false
config.assets.debug = false
config.assets.compress = false
The best way to tackle this is to profile your app startup. There are several ways that you can take, some fairly technical, but not invasive (e.g. using DTrace), others more invasive, but easier to do (e.g. monkeypatch require).
This page contains a couple of relevant sources: https://waynechu.cc/posts/196-profiling-rails-boot-time. I'd be surprised if none of the options proposed there help.
Another option can be found here: https://gist.github.com/robdimarco/e610b2b5c31c68bb13fe
The IMO easiest way to use this is as follows:
add ruby-prof to your Gemfile and run bundle install
boot an irb shell with it: bundle exec irb -rruby-prof
run the code from the snippet in the irb shell
The output there should give you a good indication where to start looking.
Thanks for pitching in folks. Just now, got it resolved.
I am using turbo-sprockets-rails-4 in which preload assets is enabled by default for dev environments.
added below config in config/environments/development.rb
TurboSprockets.configure do |config|
config.preloader.enabled = false
end
now server startup time is as fast as rails3
this is mentioned in their readme itself, but missed it while skimming through
Related
I have a really weird bug, a few hours after i start rails in production it stops being able to locate my assets. The weirdest thing is that i can "fix" by starting in development and then production works for a couple of hours and the cycle repeats. Here is a picture of my console log
console log.
I have a docker container that runs the app in production and there it works.
At first i thought it was from my docker so i tried removing it but it had no connection. I tried fixing the pathing but that breaks it even more. Here is my project in github if that is of any need (https://github.com/Bog2G/PollSite)
Try adding this in your production configuration
config.assets.compile = true
config.assets.precompile = ['*.js', '*.css', '*.css.erb']
Another option is
config.public_file_server.enabled = false
or call this command on production during deployment
RAILS_ENV=production rails assets:precompile
I want to show unbundled javascript and css of my web-application to a UI developer. I have tried adding require 'sprockets/railties'
config.assets.debug = true
in my production.rb, but it did not work and I can still see bundled, uglified css/js in my browser sources.
I tried running my production in development mode by adding rack_env development in my /etc/nginx/nginx.conf http block, but I get Bad Request due to following error:-
invalid number of arguments in "rack_env" directive in /etc/nginx/nginx.conf:16
Please help
Did you try purging and recompiling your assets by any chance? Depending on your deploy method, production assets may not be recompiled on every deploy / application start.
rake assets:clean (rake assets:clobber) for Rails 4+
rake assets:precompile
By default, config.assets.debug = true is what controls this 'bundling' behavior.
You might also try to comment out
config.assets.js_compressor = ... or
config.assets.css_compressor = ...
if you have any of those in your production.rb.
Another reason may be any sort of external cache, depending on where you host your app: Cloudflare or Heroku Asset Pipeline Cache (those usually cache based on MD5 of your assets).
And the last but not the least is... browser cache, just in case :)
When I tail the logs and hit my app, I have heroku[router] telling me I received a 500, and the app shows the usual "We're sorry, but something went wrong" message... but there are no additional details from Rails in the logs to tell me what is causing the 500.
I've read a couple of other threads that asked about this but they mostly end with people suggesting to do a rake:db migrate which fixed the error but there's no further discussion about the logging unfortunately. (And yes I'm sure there's no pending migrations 😄)
I have the rails_12factor gem installed
I've tried setting config.log_level = :debug in production.rb
I've tried creating a config variable of LOG_LEVEL set to DEBUG (which should supersede the config setting)
I've set $stdout.sync = true in config.ru as suggested here
What am I missing?
As an aside, have tried re-producing my actual problem locally with a backup of the database being used with Heroku but I can't reproduce it, so I'm finally forced to get to the bottom of this logging problem.
I first just got this to work by manually adding:
config.logger = Logger.new(STDOUT)
to production.rb but that obscured the real issue...
RACK_ENV and RAILS_ENV were both set to staging while I had the gem loading in the :production set... So although Heroku told me it was using the rails_12factor gem when the instance started, it wasn't really (I assumed it wouldn't be listed there if it wasn't a production environment, wrong assumption!)
staging.rb was loading production.rb which is why setting STDOUT there worked, thus confusing the issue further.
Thanks for the replies, and hope this helps someone else in future - go check your config variables and/or change where the gem is being loaded! :)
Debugging errors on heorku can get difficult most of the time.
For people facing a similar problem I suggest using PaperTrail heroku add-on for logging, It is free upto a certain limit.
It is realtime and provides with searching of logs, events hooks, mailing alerts etc. facilities. You will never have trouble debugging errors on heroku.
You can simply install it using the heroku cli command.
heroku addons:create papertrail
I have read dozens of posts all over the internet about this but mostly for Rails 3.
For some reason, it takes 35 seconds to load a page with a total of 34 assets in development.
I have done the following:
Set config.assets.debug = false in development.rb, but this only cuts it down to 30 seconds,
reloaded the page multiple times, but each load is just as slow,
precompiled the assets manually (although this seems to only applies in production),
looked for something like rails-dev-boost (https://github.com/thedarkone/rails-dev-boost) but cannot find anything for rails 4.
I'm developing on an ubuntu box using vagrant (https://github.com/rails/rails-dev-box). The host machine is the fastest, new MacBook Pro.
I'm almost going to throw out the asset pipeline altogether and compile the assets myself. I cannot wait 35 seconds every time I need to reload the page.
Any help on this is appreciated.
development.rb:
MyProject::Application.configure do
config.cache_classes = false
config.eager_load = false
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
config.action_mailer.raise_delivery_errors = false
config.active_support.deprecation = :log
config.active_record.migration_error = :page_load
config.assets.debug = false
config.action_mailer.default_url_options = { :host => 'localhost:3000' }
end
Edit
I think the issue is the VM. I installed ruby on my Mac using homebrew and ran the same project with the exact configuration and it loads in under 1 second. I'm not sure what the problem is.
The issue is probably with your shared_folder on Vagrant box, which can be fixed by using rsync:
Install rync on your mac: brew install rsync
In your Vagrant file, add type: "rsync" to your synced_folder: config.vm.synced_folder "[path to host folder]", "[path to guest folder]", type: "rsync"
I was experiencing 20-25 second page load times, and once I added rsync, my pages were loading in under a second. Since the shared_folder by default is only pointing to your code, it essentially has to load those files to the VM each time the page loads.
adding gem 'rack-mini-profiler' or less-easy-to-use gem 'ruby-prof' can help to find what renders slow
i have around fifty heavy js|css files and it renders pretty fast in development environment, so it is very unlikely that problem core in assets pipeline itself
I have come into an existing Rails project which claims to use memcached. As a test I tried putting an object in the cache with
Rails.cache.write("gateway", #gateway)
Then retrieving it with
Rails.cache.read("gateway", #gateway)
however this returns nil, why is this?
This is in a development environment, memcached is installed and running and should be enabled by the entries config.cache_classes = true and config.action_controller.perform_caching = true.
Rails projects use memcached in various different ways but if you are working on a rails 3 project then I would suggest they may be using the 'dalli' gem which uses a memcached session store. So using the cache could instead be done something like this session[:gateway] = #gateway and the opposite #gateway = session[:gateway] the other way it is done is memcache.set('gateway',#gateway') and memcache.get('gateway')
Would be helpful to see the configuration code. check /config/initializers/session_store.rb for something like Rails.application.config.session_store :dalli_store ............
Also as said in the comments if you are in development caching may be turned off. Check your config/development.rb file for the following:
config.action_controller.perform_caching = false
the other thing is you need to have memcached installed on your os for linux this is sudo apt-get install memcached and can be checked by ps aux | grep memcache (this should show two proccesses the grep and memcache)
Update
Should also check out the rails caching guide