Is it possible to somehow recompile app (when changing code) while in production mode, without restarting apache? I am using passanger...
thank you
Dorijan
** EDIT **
In your app's root directory:
touch tmp/restart.txt
This will restart the Rails app.
From the docs:
config.cache_classes controls whether or not application classes and
modules should be reloaded on each request. Defaults to false in
development mode, and true in test and production modes. Can also be
enabled with threadsafe!.
Terrible idea in production though as it slows down EVERY request. Best to use something like Capistrano for deployment and have it restart the server for you.
Related
I would like to install Redmine using the Bitnami stack. I have to build custom NEW pages in Redmine and perform some reporting - hence play around with some ROR code.
Can you please suggest me a good development process, as I will have to stop and restart Redmine's service upon every change.
Should I not use Bitnami for development (develop with a thin server first) and at the end merge/replace my files in Bitnami's Redmine folder?
You could switch to rails development environment. In this mode source code files are read by server upon every request.
Change database.yml, so it will have the same configuration options as in production mode. It is better to create separate database for development environment, but not necessary, since you're already developing in production.
Find your web-server configuration file and change in there environment to development.
There is other simpler way. Since (for now) you are interested only in source code updates per request, you can change only one parameter in rails configuration to do so. Open config/environments/production.rb and change line
config.cache_classes = true
to
config.cache_classes = false
Usually this option set to false in development with the following comment:
# 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 webserver when you make code changes.
I have been developing ruby on rails application since some couple of months. I use the default WEBrick server to run the applications. And I found that when I start the WEBrick server in the development and production modes, the server works more speed for production mode than for the development mode.
Is there any specific reason behind that? Can anybody explain me?
In production mode, a server loads code into the cache, which makes things quick. However, that's not the case in development mode (since you don't want to restart your webrick every time you made a change). Every request loads the according code again, which takes a bit of time.
And the most of all time-eaters is the asset pipeline. In production, you get a compiled version of your assets (javascripts and css) in maybe one or two requests. In development, you get them split, for debugging purpose (based on your environment settings, of course). And because a browser does not handle all requests simultaneously, some assets are loaded after other ones are finished loading. You can watch this behaviour with e.g. firebug's network console. That means: the more assets you have, the longer your page takes to load in development mode.
In dev mode classes are not cached, so Rails reloads all the classes each time you refresh. Also, asset compilation is not done in development (by default), so Rails reloads all the assets (CSS, Javascript etc) each time you refresh.
The difference is between 2 environments. In Rails, there are several environment. Each has his own database configuration and Rails options.
You can use the Rails.env variable to made some different change with particular environment.
By default, the development environment is without all cache and activate the auto-reloading. The production environment is with all cache.
But if you want you can make a production environment like development or development environment like production.
You can add some new specific environment too.
Creating new Environment:
Assuming you want create the hudson environment.
Create a new environment file in config/environments/hudson.rb.
You can start by cloning an existing one, for instance config/environments/test.rb.
Add a new configuration block in config/database.yml for your environment.
That's all.
Now you can start the server
ruby script/server -e hudson
Run the console
ruby script/server hudson
And so on.
I'm having a real tough time diagnosing a 500 error from my application running in production. I've had it working before, but after re-deploying via Capastrano I am unable to get it going.
Here are the facts:
The server is setup with nginx + passenger, and I'm using
PostgreSQL.
Static assets are working properly, as in I'm able to access them just fine in a browser.
I can access the rails console via RAILS_ENV=production bundle exec rails console and perform Active Record actions (like
retrieving data from the db).
Within console, I can run app.get("/"), which returns a 500 error as well (after first showing the query that was run to load
the model).
The production.log file is never written to. I've set permissions 777 on it just for the hell of it. I've also set the log level to
:debug with nothing to show for it.
The nginx log (which passenger also uses) shows no indication of errors, it just notifies about cache misses.
Because nothing of use is being logged, I have no idea what to do here. I've tried setting full permission on the entire app directory with no help. Restarted the server multiple times, nothing. The database is there and rails can clearly communicate with it. I'm not sure what I did to get it to run the first time around. I just don't know why rails isn't outputting anything to the log.
Okay, I figured this out. The app ran fine in development mode, so I knew something production-specific was screwing it up. I went into config/environments/production.rb and changes these settings:
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false # changed from true
config.action_controller.perform_caching = true # changed from false
And then after restarting passenger, rails showed me the error w/ stacktrace. Turns out I was forgetting to precompile the asset pipeline!
Things to check
1) Are you sure you are running in production environment?
Check to see if any entries are in the development.log file
2) Set up your app to email you when a 500 error occurs with a full stack trace. I use the Exception Notifier gem but there are plenty of other solutions for this.
3) When checking your app in the console are you sure you are starting the console in production mode? It is possible that the app is not starting up at all and you just forgot to set the production param thereby thinking that the app runs fine when it doesn't.
4) Are you getting an nginx 500 error or the Rails 500 error? If nginx then it is likely that your app is not starting at all and highly unlikely that you will get any rails error in your log file. The assets are static files and navigating to them proves nothing other than that they exist.
5) Are you sure you are checking the right folder on the server? Sounds really stupid but capistrano could be deploying the app to a folder that is different to the folder that nginx is looking for for your app so double check both the folder capistrano is deploying to and the folder that nginx is looking for are the same.
Just a suggestion, I would use puma rather than passenger. It's awesome with nginx.
My problem is passenger's log file (error.log) has nothing. Then it's a rotation log issue. Run
passenger-config reopen-logs
solved my problem. More.
Have you tried running in development mode to see if the error reports itself?
In Development when i change the views,controllers, routes, etc. There's no need to restart the rails server, but we do need in Production environment? Is it saving something in the memory so that we need the restart?
And about all the Gem files that we need in Gemfile (Gemfile.lock), are those Gems loaded (or save into somewhere) when we run the rails app, or is it loaded on-demand?
All of your views controllers and routes are cached in production to speed the app along. It would be a very bad thing to have to reload all of those for every request. This is taken from development.rb:
# 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 webserver when you make code changes.
config.cache_classes = false
Also, your gems are loaded when the application environment starts. Those are installed to your global gem directory by doing a bundle install. When you deploy to another server, you have to do bundle install on those as well.
The development server can afford to reload code, views, controllers, routes on every request because your requests are the only ones going to it -- and it would take more time for development if you had to restart the server on changes.
However, all those checks require re-stat(2)-ing every single file and checking the modification times on every single request. That is a lot of system calls. Reducing system calls is one top method of improving runtime and scalability of a program, so the "common case" -- millions of requests to the same code and configuration -- is optimized in the production server. But the common case of a development server is constant change.
I have a app that I'm deploying to a development server using Capistrano. I'd like to force this deployment to use the development database. So far the only way I've managed to do it is to make my production database info in database.yml equal to the development info. But this is a complete hack.
I've tried setting rails_env to development in deploy.rb but that hasn't worked.
Thoughts?
I ended up using the solution over here. Basically a recipe to replace a line in environment.rb after deploy but before restart.
The problems seems to be with DreamHost's Passenger config. It assumes you're running in production mode.
I'd use Capistrano Ext in order to define multiple deployment environments. I have used this in the past to deply staging and production installations of my apps, so I think it'd work well for you.
Jamis Buck has a writeup if you'd like an overview on how to use it.