Some standard questions:
Are you running production or development mode? How is the app deployed (Webrick, Mongrel, FastCGI, CGI)?
Try RailsPlayground. You will need to know more about your deployment before you can really figure out whether you have a performance problem.
John Burm wrote:
Take a look at a2hosting.com. I've been using them for about 6 months now for a dev environment at < $10/month . Excellent support. Very good for the $, IMO.
hth, Bill
You haven't really specified what you are deploying, how much traffic you expect and so on. Planet Argon offers a very nice shared hosting environment at reasonable rates, but don't expect to run Amazon-like traffic through it. RailsMachine and EngineYard have what appear to be great plans for larger-scale apps or ones where you need guaranteed cycles. I've read that they're worth what they charge.
The real question is this: Are you a dev who's test-driving rails to see how it works ($5 developer plan) or are you pushing something live tomorrow that has to serve hundreds of thousands of pages a day without breaking a sweat?
Rails hosting is not as commoditized as PHP and Perl (or any Windows) hosting are. Deploying a Rails app requires more from your host and more from you. If you are in development mode, it might be worth your while to get a bit of dev space on one of the less expensive hosts to try different deployments.
Hope this helps.
John Burm wrote:
If you can, splurge for a VPS at www.slicehost.com . Instead of getting a $10/month shared hosting account, skip a few latte's and get a 256MB slice for $20/month, can't beat it.
Since you had your app in 'development' mode, maybe a good question is whether you are actually wanting to deploy this app or are still 'developing' it, or even just playing with Rails to learn. Unless you are actually ready to publicly deploy - perhaps it would be cheapest, fastest and best to simply 'host' it on your local machine.
I personally have had good experiences with ServInt for VPS hosting, their plans start a little under $50 for a fully-managed server. Set it up with LiteSpeed's free server which has built in support for RoR and you have a fairly easy to setup, easy to maintain server configuration that still gives you cPanel if you should need such a thing.
Even development mode shouldn't be that slow, unless you just have a lot of queries on that page. If so, running on mongrel/fastcgi in production won't help much.
I would suggest http://www.railshosting.org/#free_rails_hosting to get a decent free account while you are testing the waters
> > I am still kind of "playing" around with Rails, although I have plans of > deploying the current website I am creating once I finish it. I don't > expect too much trafic, but I mean there are going to be a lot of people > searching through hundreds of articles and I don't want it taking 10-15 > seconds every search. It's not really traffic I am worried about, just > the speed of the things the site is doing. This will me my first rails > application deployed.
Even development mode shouldn't be that slow, unless you just have a lot of queries on that page. If so, running on mongrel/fastcgi in production won't help much.
I'm with Rick here; there's probably a better way to do whatever it is you're trying to do.
Is the site this slow during development as well? All of it, or just a single action?
Isak
I'm sure you've thought of it, but the only time I've had a slow system (without heavy traffic), is improper use of the joins, or not using eager loading.
For Example,
Myobject.find(:all,:include=>'childtable')
One of the big things, is that rails makes it easy to do something this
<%=Myobject.childtable.full_name-%> Doing that 500 times in a view, will make 500 database calls unles you use eager loading.
What does:
Myobject.childtable.each {}
Do? I thought it would just query the database once, grab all the results, and loop through them.
Right, but that's not exactly what the parent meant. Consider...
model... Person has_one Address
controller.... @people = Person.find(:all)
view....
<% @people.each do |person| %> <%= person.name %> lives in <%= person.address.city %> <% end %>
If you've got 500 people, you're going ot have 501 database queries. One to get all the people, and one to get each person's address.
Change the controller to... @people = Person.find(:all, :include => [:address])
And now Rails does a join query so you only have one database query.
-philip
I keep thinking it has to be simpler than an unoptimized database query. The OP described his application and it seemed like a fairly straightforward posts/comments kind of thing. The most glaring thing that can bring a Rails app to its knees is deploying as CGI and not FCGI. Could this be it?
Ok, let's presume it was deployed as FCGI or Mongrel. What do the logs look like for a slow page? That would at least provide a hint about whether the database was the bottleneck.
Finally, how about creating a dirt-simple action:
def dirt_simple @post = Post.find :first end
and a dirt simple view <%= @post[:id] %>
How fast is that? If it's not fast, then you can take your focus off the database and point it back to your server config.
Here's the deal. It's fast on the local machine under WEBrick. Ok, that's understandable -- long-running process, no network overhead, but wait! The database on the local machine should be *slower*. So, as I continue attempt inference from this thread, it tells me that the performance problem is in the server on the remote host or the host itself.
My first guess was that the deployment was straight CGI and that's what was causing the holdup. If I'm not right, it'll show up in the logs.
--steve
Philip Hallstrom-8 wrote:
[railsplayground.com]
Now here's my question. They offer two plans, one for $60 a month but no support for lighttpd/mongrel servers and then one for $108 a month with support for lighttpd/mongrel servers. Is it worth it to go all the way to $108 for the servers for pay $60 and go with fastcgi?
Those prices are actually per _year_... apologies if that's already clear. So, $9 per month gets you two mongrel instances (the least you really need but also more than enough to get going), and you can add more instances for under $4 a month each.
I'm not affiliated, though I have been a customer for over a year.
That's odd. It is in your database access. I don't suppose you'd like to put a pastie up of the code for the action, eh?
Petr Janda-2 wrote:
I think it's in the database because of this in the log:
Completed in 0.18064 (5 reqs/sec) | Rendering: 0.02450 (13%) | DB: 0.11660 (64%) | 200 OK
Notice that DB is 64% of the time.
Still, you're right, 5 req/sec should not be a big deal.
I'd still like to know if it was deployed as a CGI because that's then only time I've ever seen such gummy behavior.
Rob Nichols-2 wrote: