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.
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.
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.
I'm learning Ruby on Rails. At the moment I'm just running my site locally with rails server in the OS X Terminal. What changes when a Rails site is run on a production box?
Is the site still started with rails server?
Any differences with how the db is setup?
Note: I'm running Rails 3.
A rails app can be run in production calling rails server -e production, although 99% of the time you'll be serving on something like passenger or thin instead of WEBrick, which means there's a different command to start the server. (thin start -e production for instance)
This is a complicated question, but the best place to start learning about the differences would be to look at the specific environment.rb files. When rails boots up it starts with the environment file that matches the called environment, ie if you start it in development it begins by loading your development.rb file, or if you're in production it will load the production.rb file. The differences in environments are mostly the result of these differences in the various environment config files.
Basically if a Rails 3.1 app is in production mode, then by default it is not going to be compiling assets on the fly, and a lot of caching will be going on that isn't happening in development. Also, when you get error messages they will be logged but not rendered to the user, instead the static error page from your public directory will be used.
To get more insight into this, I would suggest reading the relevant rails guides:
Rails Initialization Guide: http://guides.rubyonrails.org/initialization.html
Rails Configuration Guide: http://guides.rubyonrails.org/configuring.html
There are two contexts you can use the word "production" here. One of them is running the server in production mode. You can do this locally by,
RAILS_ENV=production ./script/server
The configuration for this is picked up from config/environments/production.rb. Try comparing this file with config/environments/development.rb. There are only subtle differences like caching classes. Development mode makes it easier so that it will respond to any changes you make instantly. Plus there are two different databases (by default) will be used namely yourproject_development and yourproject_production if you choose to run your server in either of these modes.
On the other hand, rails deployment to a production box is something different. You will need to pick your server carefully. You may have to deal with a deployment script may be capistrano. You may also need a load balancer such as netgear. The database also may require a deep consideration like size expectation, master/slave clustering etc.,
Note: I have never used Rails 3. This answer is biased towards 2.3.x.
I have a Passenger-based production Rails application which has thousands of users. Occasionally we need to apply a code patch (we use git) and the current process for doing this (you can assume there are no data migrations) is:
Perform git pull origin [production-branch-name] on the server
touch tmp/restart.txt to restart Passenger
This allows us to patch the server without having to resort to putting up a maintenance page, which is great, but it doesn't feel quite right since it's not actually a proper 'deployment', and we still need to manually update the revision file and our deployment doesn't appear in the Hoptoad or NewRelic services we use.
Ideally I would run cap production deploy and just let the standard Capistrano deployment script take care of everything, but is this a dangerous thing to do without putting up a maintenance page? This deployment process seems to be fairly safe in that the new revision is deployed to a completely separate folder and only right at the end of the process is a symlink re-created to switch the currently deployed version, but I'm still fairly paranoid about this somehow resulting in a lost or failed request.
No problems here doing cap production deploy. If the deployment fails then the previous release is still good. Nothing will fail as the old release is loaded (cached) in the current Passenger process. The touch tmp/restart.txt will pick up the new release and all is good in the world.