[email protected] wrote:
On Jan 30, 8:56 pm, Alex W. [email protected]
wrote:
Josh G. wrote:
can someone make any suggestions for a host geared
towards Rails applications? That’s not overly priced, I am very limited
on money right now.
http://railsmachine.com/http://textdrive.com
–
Posted viahttp://www.ruby-forum.com/.
I would suggest http://www.railshosting.org/#free_rails_hosting to get
a decent free account while you are testing the waters
What I am really looking for is a host to use once I have the
application finished, I can run and test the application on my computer,
so that’s not a problem. I need a reliable host that I don’t need to
worry about switching from whenever I do start getting bigger traffic.
Josh G. wrote:
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.
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.
Isak H. wrote:
On 1/31/07, Rick O. [email protected] wrote:
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
On my computer running on a Webrick server it’s lightning fast. There is
no lag and it runs perfectly fine. I’m am not sending many queries. The
most cluttered page would probably be the display article page where I
query for the article information and then query for all the comments
that belong to that article, but those are the only 2 queries that I am
sending. I don’t understand why that would be so laggy, my basic code
looks like:
@article = Article.find(params[:id])
Display article information
render(:partial, :article_comments, @article.comment)
Display the comments
Note the above was written by hand so I’m sure it contains mistakes but
you get the general idea.
What I am really looking for is a host to use once I have the
application finished, I can run and test the application on my computer,
so that’s not a problem. I need a reliable host that I don’t need to
worry about switching from whenever I do start getting bigger traffic.
You could try dreamhost.com - with a coupon you might just spend $10 for
the first year. Search google from dreamhost coupon. There is a
dreamhost wiki with Rails deployment tips.
Stephan
<%=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
David H. wrote:
Josh G. wrote:
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.
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.
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 H.-8 wrote:
Do? I thought it would just query the database once, grab all the
And now Rails does a join query so you only have one database query.
-philip
–
View this message in context:
http://www.nabble.com/-Rails--The-speed-of-Rails-tf3145992.html#a8742978
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
[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 J.-2 wrote:
Rendering within layouts/articles
Rendering articles/show
Completed in 0.18064 (5 reqs/sec) | Rendering: 0.02450 (13%) | DB:
0.11660 (64%) | 200 OK [http://www.joshgilman.com/articles/show/1]
I blocked my IP out of course.
–
–
View this message in context:
http://www.nabble.com/-Rails--The-speed-of-Rails-tf3145992.html#a8743961
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
Steve R. wrote:
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 H.-8 wrote:
Do? I thought it would just query the database once, grab all the
And now Rails does a join query so you only have one database query.
-philip
–
View this message in context:
http://www.nabble.com/-Rails--The-speed-of-Rails-tf3145992.html#a8742978
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
I share the same feelings, I’m thinking it’s NetFirms being cheap and
running it on CGI, hence why I was asking for a better host. Sample logs
look like:
Processing ArticlesController#show (for ... at 2007-01-31
21:57:03) [GET]
Parameters: {“action”=>“show”, “id”=>“1”, “controller”=>“articles”}
Rendering within layouts/articles
Rendering articles/show
Completed in 0.18064 (5 reqs/sec) | Rendering: 0.02450 (13%) | DB:
0.11660 (64%) | 200 OK [http://www.joshgilman.com/articles/show/1]
I blocked my IP out of course.
I would recommend also to subscribe to the new group:
http://groups.google.com/group/rubyonrails-deployment?hl=en
We are using shared and cheap hosting from RailsPlayground, for some
of our proyects and it works great, the best part is the support.
–
Aníbal Rojas
On Jan 30, 8:41 pm, Josh G. [email protected]
Steve R. wrote:
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?
How do you see its in the database ? 5 requests per second should not be
noticable, if there is only one per hour.
I timed access to the page from my machine at 3.5 seconds compared to
yahoo.com at 0.5 seconds. So something is likely to be wrong.
Could the OP determine just how the Rails machinery is invoked?
Stephan
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 N.-2 wrote:
–
View this message in context:
http://www.nabble.com/-Rails--The-speed-of-Rails-tf3145992.html#a8752373
Sent from the RubyOnRails Users mailing list archive at Nabble.com.