Heroku performance vs local machine - ruby-on-rails

I'm running a ruby on Rails service. Ruby 2.0 and rails 4.0 The job on heroku takes ~2x the time it does on my local machine. I would expect the processing elements to actually run faster on the big *#!# server than on my macbook air.
sorry for the lousy formatting Times are in seconds 1.00000
Herok Macbook Air delta
job_id=Job.where(id:user.id, active:true).pluck(:id)[0]___t1=0.003 _t2= 0.126_delta=0.123
{job Prep}_____________________________________t1= 0.00_t2=0.00_delta=0.00
imagedata=Jobimage.find_by(job_id: job_id, level:0)___ t1=0.349 t2=0.044 delta=0.305
image=Marshal.load(imagedata.data) _______________t1=0.374 t2=0.096 delta= 0.278_
Job processing ________________________________t1= 0.51 t2=0.328 delta=0.182
render json:answer.to_s_________________________t1=0.51 t2=0.328 delta0.182
Except for the Job -processing block, these are statements bracketed by logging statements
I'm really surprised by 4 and 6
Can anyone explain why Heroku would be getting the stuffing kicked out of it my my notebook
thanks

You're one of many (hundreds? thousands?) of people sharing that physical box, and Heroku has no incentive to make your code fast for a free instance. Your Macbook Air is doing (more or less) one thing.

I would look into the delayed_job gem. Judging by the things you have timed in your breakdown, I don't think it will apply directly to what you are trying to accomplish, but it might be useful in a different part of your project.

Related

Rails Server Memory Leak/Bloating Issue

We are running 2 rails application on server with 4GB of ram. Both servers use rails 3.2.1 and when run in either development or production mode, the servers eat away ram at incredible speed consuming up-to 1.07GB ram each day. Keeping the server running for just 4 days triggered all memory alarms in monitoring and we had just 98MB ram free.
We tried active-record optimization related to bloating but still no effect. Please help us figure out how can we trace the issue that which of the controller is at fault.
Using mysql database and webrick server.
Thanks!
This is incredibly hard to answer, without looking into the project details itself. Though I am quite sure you won't be using Webrick in your target production build(right?), so check if it behaves the same under Passenger or whatever is your choice.
Also without knowing the details of the project I would suggest looking at features like generating pdfs, csv parsing, etc. Seen a case, where generating pdf files have been eating resources in a similar fashion, leaving like 5mb of not garbage collected memory for each run.
Good luck.

How can I benchmark why Ruby is suddenly so slow on my machine?

I've been developing Ruby on Rails on my Macbook Pro for quite some time, but recently I'm starting to notice, that everything is just taking forever.
Even simple things like rake -T take over 30 seconds to complete.
$ time rake -T
real 0m35.113s
user 0m12.997s
sys 0m1.828s
When I do the same thing on my VPS, which has much less memory and CPU available, it runs about three times as fast. I'm using Ruby 1.9.2 installed via RVM on OS X Lion.
Is there anything that I can check/do to get some instant improvement? I was thinking about upgrading to SDD, but I don't want to make such a decision too early.
It could be some gem's fault, perhaps one that adds a lot of middleware.
This might help you.
Also, please try installing 1.9.3, it should perform better at loading.
Edit
Just wanted to add that, if all else fails, [the Mac counterpart of] good ole strace could be of some help.

Rails rake: test are slow

I've been developing RoR apps for about a month in my Windows Laptop, however everytime that I run the tests it takes forever to finish (10+ minutes).
On a MacBook Pro with similar hardware it runs in a fraction of the time (2 minutes).
Can you guys give me any tips for speeding the whole thing up? or should I consider switching my RoR environment to a Linux/Mac box?
I do most of my ruby development in an Ubuntu VM, just because it is easier to get everything together under linux (I imagine the same applies to OSX). RVM makes my life so much easier.
If your hardware can support it and you don't mind working in a VM, may I suggest you give it a try? VM development has its advantages (namely, taking daily snapshots so you can roll back environment changes) and disadvantages (you lose a bit of speed, but not much these days) but I think it is worth it overall.

Getting low rails mongrel requests per second (8-15 per second)

So I have tried this out on multiple computers with multiple setups (servers/apps) and I seem to consistently get Rails completing 8-15 requests per second even for doing selects on empty tables with 1 field. I think I'm doing something wrong here because I've read a lot of stats online where people are getting 60-200 with mongrel. So being down at 8 seems just awful. The first app I tested this on was a little more involved and had 2 queries in 1 controller but they were just selecting a few rows, not a big deal.
Is there some trick to this I don't realize? Ruby.exe is taking up nearly 50% of my cpu cycles but still this is pretty bad. I feel like I've tried this when messing with rails last year and have gotten something like 50 requests per second. Is it possible that routing is screwed up some how?
Any advice would be greatly appreciated. Even info as far as profiling tools go so I could at least figure out WHERE the problem is occurring.
Thanks ahead of time.
If you're on windows then that seems about right. Rails runs terribly slow on windows. Try running it on a linux box, or a mac if you have one. You could also try heroku. They have a free starter plan you can use for development.
If you must run in a windows environment you could try jruby for some extra speed.

How can I find out why my app is slow?

I have a simple Rails app deployed on a 500 MB Slicehost VPN. I'm the only one who uses the app. When I run it on my laptop, it's fast enough. But the deployed version is insanely slow. It take 6 to 10 seconds to load the login screen.
I would like to find out why it's so slow. Is it my code? (Don't think so because it's much faster locally, but maybe.) Is it Slicehost's server being overloaded? Is it the Internet?
Can someone suggest a technique or set of steps I can take to help narrow down the cause of this problem?
Update:
Sorry forgot to mention. I'm running it under CentOS 5 using Phusion Passenger (AKA mod_rails or mod_rack).
If it is just slow on the first time you load it is probably because of passenger killing the process due to inactivity. I don't remember all the details but I do recall reading people who used cron jobs to keep at least one process alive to avoid this lag that can occur with passenger needed to reload the environment.
Edit: more details here
Specifically - pool idle time defaults to 2 minutes which means after two minutes of idling passenger would have to reload the environment to serve the next request.
First, find out if there's a particularly slow response from the server. Use Firefox and the Firebug plugin to see how long each component (including JavaScript and graphics) takes to download. Assuming the main page itself is what is taking all the time, you can start profiling the application. You'll need to find a good profiler, and as I don't actually work in Ruby on Rails, I can't suggest any: google "profile ruby on rails" for some options.
As YenTheFirst points out, the server software and config you're using may contribute to a slowdown, but A) slicehost doesn't choose that, you do, as Slicehost just provides very raw server "slices" that you can treat as dedicated machines. B) you're unlikely to see a script that runs instantly suddenly take 6 seconds just because it's running as CGI. Something else must be going on. Check how much RAM you're using: have you gone into swap? Is the login slow only the first time it's hit indicating some startup issue, or is it always that slow? Is static content served slow? That'd tend to mean some network issue (either on the Slicehost side, or your local network) is slowing things down, assuming you're not in swap.
When you say "fast enough" you're being vague: does the laptop version take 1 second to the Slicehost 6? That wouldn't be entirely surprising, if the laptop is decent: after all, the reason slices are cheap is because they're a fraction of a full server. You're using probably 1/32 of an 8 core machine at Slicehost, as opposed to both cores of a modern laptop. The Slicehost cores are quick, but your laptop could be a screamer compared to 1/4 of core. :)
Try to pint point where the slowness lies
1/ application is slow, or infrastructure (network + web server)
put a static file on your web server, and access it through your browser
2/ If it is fast, it is probable a problem with application + server configuration.
database access is slow
try a page with a simpel loop: is it slow?
3/ If it slow, it is probably your infrastructure. You can check:
bad network connection: do a packet capture (with Wireshark for example) and look for retransmissions, duplicate packets, etc.
DNS resolution is slow?
server is misconfigured?
etc.
What is Slicehost using to serve it?
Fast options are things like: Mongrel, or apache's mod_rails (also called passenger phusion or
something like that)
These are dedicated servers (or plugins to servers) which run an instance of your rails app.
If your host isn't using that, then it's probably defaulting to CGI. Rails comes with a simple CGI script that will serve the page, but it reloads the app for every page.
(edit: I suspect that this is the most likely case, that your app is running off of the CGI in /webapp_directory/public/dispatch.cgi, which would explain the slowness. This tends to be a default deployment on many hosts, since it doesn't require extra configuration on their part, but it doesn't give good performance)
If your host supports "Fast CGI", rails supports that too. Fast CGI will open a CGI session, and keep it open for multiple pages, so you get much better performance, but it's not nearly as good as Mongrel or mod_rails.
Secondly, is it in 'production' or 'development' mode? The easy way to tell is to go to a page in your app that gives an error. If it shows you a stack trace, it's in development mode, which is slower than production mode. Mongrel and mod_rails have startup options to determine whether to run the app in production or development mode.
Finally, if your database is slow for whatever reason, that will be a big bottleneck as well. If you do have a good deployment (Mongrel/mod_rails/etc.) in production mode, try looking into that.
Do you have a lot of data in your DB? I would double check that you have indexed all the appropriate columns- because this can make a huge difference. On your local dev system, you probably have a lot more memory than on your 500 mb slice, which would result in the DB running a lot slower if you have big, un indexed tables. You can also run the slow queries logger in MySql to pinpoint columns without indexes.
Other than that, yes- passenger will need to spool up a process for you if you have not been using the site recently. If this is the case, you should see a significant speed increase on second, and especially third and later page loads.
You might want to run a local virtual machine with 500 MB. Are you doing a lot of client-server interaction? Delays over the WAN are significant
You might want to check out RPM (there's a free "lite" version too) and/or New Relic's Tune Up.
Your CPU time is guaranteed by Slicehost using the Xen virtualization system, so it's not that. Don't have the other answers for you, sorry! Might try 'top' on a console while you're trying to access the page.
If you are using FireFox and doing localhost testing (or maybe even on LAN) you may want to try editing the network.dns.disableIPv6 setting.
Type about:config in the address bar and filter for network.dns.disableIPv6 and double-click to set to true.
This bug has been reported mainly from Vista OS's, but some others as well.
You could try running 'top' when you SSH in to see which process is heavy. If you also have problems logging you, perhaps you may try getting Statistics in the Slicehost manager.
If you discover it is MySQL's fault, consider decreasing the number of servers it can spawn.
512 seems decent for Rails application, you might have to check if you misconfigured too.

Resources