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.
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 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.
I'm developing a new site based on Ruby on Rails 3 beta. I knew this might be a bad idea considering it's just beta, but I still thought it might work.
Now though I'm having HUGE problems with Rails consuming huge ammounts of memory.
For my application today it consumes about 10 mb per request and it doesn't seem to release it either. So I thought this might be because of bloat in my application and thus I created a test app just to compare.
For my test app I just generated a model with a scaffold and then created about 20 records on this model.
I then went to the index page and hit refresh and I could immediately see memory taking off! Less than my app but still about 1-3 mb per request.
I'm working in OSX Leopard, with Ruby 1.8.7, Rails 3.0.0.beta and a SQLLite db for development.
Does anyone recognize my problem?
I would really appreciate some help here. :/
Thanks!
Well, you should consider how a production Rails app would be served. For example, the above setting (with regards to caching) is typically enabled for the production environment and you should also compare performance with your app running under Passenger (Apache or Nginx).
I do believe there is an easy means to force Passenger to play nicely in dev mode as well.
There were some memory leakage issues in the Rails 3 betas. Is there a reason you're not on 3.0.6?
Edit: D'oh, just saw the date this was asked.
I am running a rails app on Dreamhost.
Today, a strange thing happened.
A page is almost loaded (it seems to be fully loaded but the status is not 'Done') and after that, the app didn't respond on any page.
I checked out the log and even the log was not complete.
How do I know it?
There are 3 missing images on the problem page and the log showed only 2 missing images and stopped there.
So I guess that something happened between the 2nd and the 3rd missing images.
I couldn't even start 'script/console production'.
After 14 minutes, it began to behave normally.
I asked the hosting company and they said that the process was killed due to over-use of memory.
Probably something was running heavily during the period.
The same thing happened one more time.
I had to kill the process to unlock the stucked app.
Passenger version is 2.2.4 and rails version is 2.3.2.
I am afraid that I can't give more specific info.
What do you guess cause such a problem?
Thanks.
Sam
As theIV stated, look at the last action called. Start this up locally and try to go through what was happening on the server to see if it's reproducable, or if you just get any sort of general hiccups. I've run Rails apps on Dreamhost for a while, and have not experienced this before, so I would guess that it's not Dreamhosts fault, but there is no 100% on that.
Good luck!
This sounds pretty app specific. I would start by looking at what action was last hit before the process started hoggin' and then work backwards from there to see if there are any calls that might be doing something you weren't expecting. Other than that, no clue. :(
Try using NewRelic RPM or TuneUp Lite to see what process is chunking most of your memory. You can run them locally but it would be better to test it on production.
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.