I am working on a pretty large rails project with a lot of routes. If rails is in development mode the app runs extremely slowly because it has to generate the routes repeatedly. I've tested this a couple of times by removing most of the routes and our app is nearly instant in bringing up our pages rather than the 10 or so seconds it usually takes. What I'm trying to find out is how I can stop rails from regenerating the routes on every request when in development mode. Is there a way to cache it or just stop it from regenerating?
I wouldn't advise it, but set cache_classes to true in your config. You'll have to restart the server every time you want to test a code change though.
Did you get anywhere with this?
I'm a little late to the party, and I don't have a direct answer for stopping the regeneration of routes, but would you accept speeding up other parts of the development environment as a compromise? If so, it's worth checking out the Rails Development Boost gem. I've had some great speed increases from there.
Related
We have a web-app here that makes hundreds of calculations with money and other very specific numbers. It has been developed in Rails 3, which I have not much experience.
Recently, I have noticed that even in Digital Ocean server, where it runs for production, whenever an user requests to open some page for example, that does any query to get data from the database, everyone else gets stuck until the processing finishes.
It just looks like rails is running on a "single-threaded" mode, similar to running the same scenario with Tomcat in development mode in Eclipse.
Is there any trick to make it work "multi-threaded"?
I don't see any reason or even logic for it to run like this, there's no sense in making everyone wait until the request of another user finishes.
Thanks in advance to everyone!
Well, I've found the solution.
To enable Rails with WEBrick to work in a "multi-threaded" way, you'll have to simply go to the config file, and add :
# Enable threaded mode
config.threadsafe!
After that, restart the server and the trick is done. It "solved" my problem, but ended up creating a thousand others, cause the application wasn't developed thinking about a "threadsafe" scenario, which means, that everytime I try to run similar requests at the same time, the application mixes up everything in memory, crashing.
Well, one problem at once!
The original from this topic is solved.
I work with several Rails apps, some on Rails 3.2/Ruby 2.0, and some one Rails 2.3/Ruby 1.8.7.
What they have in common is that, as they've grown and added more dependencies/gems, they take longer and longer to start. Development, Test, Production, console, it doesn't matter; some take 60+ seconds.
What is the preferred way to first, profile for what is causing load times to be so slow, and two, improve the load times?
There are a few things that can cause this.
Too many GC passes and general VM shortcomings - See this answer for a comprehensive explanation. Ruby <2.0 has some really slow bits that can dramatically increase load speeds; compiling Ruby with the Falcon or railsexpress patches can massively help that. All versions of MRI Ruby use GC settings by default that are inappropriate for Rails apps.
Many legacy gems that have to be iterated over in order to load files. If you're using bundler, try bundle clean. If you're using RVM, you could try creating a fresh gemset.
As far as profiling goes, you can use ruby-prof to profile what happens when you boot your app. You can wrap config/environment.rb in a ruby-prof block, then use that to generate profile reports of a boot cycle with something like rails r ''. This can help you track down where you're spending the bulk of your time in boot. You can profile individual sections, too, like the bundler setup in boot.rb, or the #initialize! call in environment.rb.
Something you might not be considering is DNS timeouts. If your app is performing DNS lookups on boot, which it is unable to resolve, these can block the process for $timeout seconds (which might be as high as 30 in some cases!). You might audit the app for those, as well.
Ryan has a good tutorial about speeding up tests, console, rake tasks: http://railscasts.com/episodes/412-fast-rails-commands?view=asciicast
I have checked every methods there and found "spring" the best. Just run the tasks like:
$ spring rspec
The time for your first run of spring will be same as before, but the second and later will be much faster.
Also, from my experience, there will be time you need to stop spring server and restart when there is weird error, but the chance is rare.
For ruby 2 apps, try zeus - https://github.com/burke/zeus
1.8 apps seem to boot much faster than 1.9, spork might help? http://railscasts.com/episodes/285-spork
I'm new to Rails 3.
I use ruby 1.9.2 and Rails 3.0.7 and Windows 7
So, my problem
When I start a server this process last for a minute
When I try to access it from the browser (http://127.0.0.1:3000/demo/index) this page loads very long (from 1 minute and more)
I tried to turn off the antivirus, user faster_require gem... I just have no clue what to do...
Whats is the problem?
When Rails starts up it needs to load the entire stack as well as a good chunk of your application, so this can take some time. It's not abnormal for it to take twenty to thirty seconds to get ready even on a current machine.
Generally this isn't an issue as the framework will do smaller reloads while it is running if in development mode. Anything you change in app/ or config/routes.rb will be detected and adjusted for between requests.
The first page load is always the slowest, but after that you should have a very responsive server. If not, something might be amiss configuration-wise.
Some people suggest using Mogrel instead of webrick. I'd recommend to give it a try.
I had this problem with a non-rails project and Apache. Disabling IPv6 fixed the problem. YMMV.
I am scratching my head over for this issue for last few weeks.
My local rails dev environment has been so slow for some reasons. I have production environment working as quick as a bullet on the servers. But with the same code, my dev environment is taking so slow and I have decided to dig into that further.
I have found that the problem exists with two of my main models. I could identify it with Console in the terminal.
Admin.last
#(super quick, no records there)
Club.last
#(super quick, about 1400 records there)
User.last
#(super slow, about 3 seconds. but no records in there yet!!!!)
Site.last
#(super slow,about 3 seconds, too.. but this one has about 4000 records)
Admin and User has almost the same number and type of fields except User has a photo (using Paperclip). But paperclip is working fine with Club anyway.
Any help will be appreciated.
Thanks.
EDIT: I have found more precise issue there. In both User and Site models, I have this reference which is slowing things down on my dev env.
include ActionController::UrlWriter
I know we should not use URL in the model level. But I have to use it. The question now is why the heck it's slow to use it only on Dev env, not on production?
Thanks.
In the development environment code is reloaded after each request and not cached. This means you can make changes to the code and just refresh the page and not have to refresh the server.
In production mode routes/models are cached as these are less likely to be edited between requests without a server restart.
it's because your URL are reload in each time. So take some times. In production there are no reload of your route.
I heard Kevin Skoglund (lynda.com) say that it is good practice to get in the habit of restarting Webrick frequently during development. Although generally you do not need to restart Webrick to see your changes, he implied that there are particular times when this may be needed? Does anyone know what those circumstances might be? This made wonder if Webrick is kind of flaky.
If you are working through the Lynda.com tutorials, then you are working with a much earlier version of Rails then the most recent release (2.3.2).
The short answer is, large amounts of restarts are no longer necessary when working in the development environment. I think Kevin has you restart the server every time you change a Model object, but that isn't the case anymore.
The general rule of thumb is: restart every time you change something in the config or lib folder . . . any other code changes shouldn't necessitate a restart. It is also a good idea to restart when you change your routes.rb file as well, although when working with it today I noticed it is not a hard and fast rule.
The reason for all of the server restarts isn't necessarily because your webserver (webrick, mongrel, phusion passenger) is flaky, but because when your Rails app has started up, there are certain things loaded into memory, load paths, initializers, environment data. When you make a change to one of these files, you want to restart your application so that the changes take place (as opposed to the old stuff that is still running in memory)
You'll need to restart if you change your database schema, or if you add/change a constant.
I think Rails uses Mongrel by default for development now, but those still apply.