I am using Ruby on Rails under windows, installed with railsinstaller. Everything works fine, except that any command such as rails console or bundle exec rake db:migrate takes on average 8 seconds before executing. (rails s and rails -v are exceptions and take about 1 to 2 sec to launch, which is still abnormally high). I am not talking about the time of the entire command, just the time between when I hit enter and when I see the first output.
During this time, one core of my processor is working at 100%, and there is no load on the hard drive. I really feel like that I am waiting for some kind of timeout to expire, because I don't see why rails console should take that much processing power (I have a Core 2 Duo processor).
Do you have experienced this kind of problem ? What can it be ? How can I investigate this ?
It is spinning up your Rails environment, not just loading an executable. It is not Windows specific. It takes about 10 seconds on my Core2 Duo iMac. I've seen similar delays on Linux boxes. Here is an article that gives some hints that may help.
rails-3-osx-speed-up-console-loading-time
Related
We have JUnit tests that boot up the entire server and then test some functions in the booted server. However this takes a lot longer than when simply booting the server regularly through it's main function, outside of a a junit test. Why could that be?
More concretely, we're using the dropwizard framework with a jetty server. The logs I get after starting within a unit test are
INFO [2022-09-19 15:12:45,985] org.eclipse.jetty.server.Server: Started #60649ms
and the logs I get with a regular application start are
INFO [2022-09-19 15:15:06,887] org.eclipse.jetty.server.Server: Started #13093ms
As you can see, it's around 6 times faster outside of JUnit.
Is there any reason for that? The server spawned in junit isn't 100% identical to the other one but it comes pretty close. I don't see any reason why it should just be that much slower. Is there any "known" reason why this is happening or is it more likely that's something about how we spawn the server in our testing environment?
When trying to find the bottleneck, I couldn't identify one single place that runs slower. It seems that everything is just running slower in the tests.
Edit:
An additional information is that I run on an M1 mac. My previous results, where the tests were 6 times slower than the server start, were with brew install --cask adoptopenjdk11. However when I switched to the brew install --cask zulu-jdk11, now the disparity is much smaller: 18 seconds for test runs, 12 seconds for server starts. It doesn't make the mystery smaller, but it makes me a bit happier.
We've got a fairly large test suite with lots of integration tests, with the following setup:
REE ree-1.8.7-2011.03 under RVM
test/unit with shoulda 2.11.3
integration tests with capybara 1.0.0 in rack/test mode
Rails 3.0.10
spree 0.60.0
Occasionally, but not always, after running the integration test (via rake test:integration) and a couple of test failures or errors, the ruby process with the tests will hang for minutes with full CPU (well, core) utilization, apparantly churning away on something, and then finally display the error output.
My Google-Fu fails here.
Does anybody have suggestions or know of bugs in this area ?
I have an application that uses rufus-scheduler to run a variety of background tasks. After recently upgrading to Ruby 1.9.2, we continue to have intermittent segmentation errors and/or bus errors. The error will occur in different libraries.
The one thing that I've identified is that the same functions that will cause a segmentation fault when running under rufus-scheduler will NOT fail when run from a console.
This occurs on two platforms (OSX for development, ubuntu for production) in the same way.
Does anyone have any ideas on what differs in the runtime between the rufus-scheduler environment and running something straight from "rails c" console?
Thanks in advance...
Russell
You seem to imply it worked with Ruby 1.8.x. What Ruby 1.9.2 patchlevel anyway ?
Rufus-scheduler is a very dumb library, you could replace it altogether with things like
Thread.new do
loop do
sleep 60 * 60
trigger_my_hourly_task
end
end
Thread.new do
loop do
sleep 24 * 60 * 60
trigger_my_daily_task
end
end
and see if the problem still occurs.
There is no rufus-scheduler environment, rufus-scheduler is pure-ruby, it lives in the environment of your server and your rails application. Running things in the "rails c" console is running stuff in a brand new process, with no accumulated memory usage, it's "blue sky".
If you really think it's a rufus-scheduler issue, you should be able to come up with a detailed way of reproducing the issue.
Newbie here. I created a rails project in rubymine to run the default index.html from public folder I pressed 'shift' + F10 key. This is same as rails server from the terminal. This is what I get:
/home/bubble/.rvm/rubies/ruby-1.9.2-p180/bin/ruby -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) /home/bubble/Desktop/Hard Boiled Bubble/bubbles/script/rails server -b 0.0.0.0 -p 3334 -e development
=> Booting Mongrel
=> Rails 3.1.0.rc1 application starting in development on http://0.0.0.0:3334
=> Call with -d to detach
=> Ctrl-C to shutdown server
Nice clean. But now I cannot shutdown the server. It simply doesn't work. Neither from terminal nor rubymine. I have to kill the process from the system monitor everytime.
Any clues, of what can be wrong in my set up? Is is because of rails 3.1.0.rc --pre ??
Got similar issue with Rubymine 3.1 (it do not seems to be a Rubymine issue) and rails 3.0.9 (it also do not seems to be a Rails issue). Om my computer I have the same problem by running the erver from the console.
Try running rails s in the console from your application directory, and stop the process (server) by pressing Ctrl+C.
On my Ubuntu 11.4 + Rails 1.9.2 (via RVM) it doesn't work as well, proving the issue do not come from Rubymine.
Looking around the web, it is quite common that ruby server "stale", but it is the very first time I see it, and didn't get the solution for now (sorry for that).
Last but not least ! Process stale with all ruby server I tried : Webrick, Mongrel & Thin. Making me think, it is a ruby issue, it seems that the stop signal does not arrive to the server...
I'll also be glad, if somebody has some more clues to fix this.
This is actually quite a common that myself and other developers see. It's nothing to do with the rails version. It happens in all versions. It's just that the server becomes a detached process and can be hard to find.
However I've learned to cope with it pretty well thanks to things I learned:-
Always use the red square to stop the server, not the red X.
If the server hangs, rather than rebooting you can just use the menu option for run... and change the port number, say from 3334 to 3335 (and so on). It sounds bad but it really doesn't hurt and only take 3 seconds...
If necessary you can also keep a terminal window open and run the server from that and just use rubyMine for editing, but then you are missing out on a lot of rubyMine features and also you have to keep both environments working ok.
It may be specific to Ubuntu as that is where I have seen it too.
I've just upgraded to rails 3. Beside some problems on the page I experience as well a strange latency after running the test environment for a while... The speed is normal but after a few clicks on the page, it suddenly "freezes" and needs about a minute to load the page. Unfortunately it doesn't matter where I click though. Just after the test environment was running for a while it shows up to suddenly have this problem. Even when I want to stop the server it needs a minute to do so. Restarting the server let it working for a while
Thanks for any help
Markus
If you are on Mac or Linux, try installing RVM and installing Ruby Enterprise Edition .