Rails - Sep 2006 - Common performance issues

Hi,

When writing a Rails app, what common tasks can likely result in
performance issues?

The one I''m aware of is something like:
Model.find(:all).each do |elem|
  # do stuff
end

Especially when there''s lots of elements in the Model.    What other
ones are there?

Also, does Rails do caching of queries?  If I''m in a view and I do:
<% if user.admin? %> ...

and then later on in that same view, I have the same code again, does
that execute two queries?

Joe


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

joevan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Hi,
>
> When writing a Rails app, what common tasks can likely result in
> performance issues?
>
> The one I''m aware of is something like:
> Model.find(:all).each do |elem|
>   # do stuff
> end
>
> Especially when there''s lots of elements in the Model.    What
other
> ones are there?
>
> Also, does Rails do caching of queries?  If I''m in a view and I
do:
> <% if user.admin? %> ...
>
> and then later on in that same view, I have the same code again, does
> that execute two queries?
>
> Joe
Another one:
What''s a faster way to write:

class User <  AR
  has_many :comments
  def number_of_comments
    comments.size
  end
end

(if I don''t want to do caching).  I assume that calling
number_of_comments creates AR objects for each comment.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Joe-

You may find it useful to use "tail" to monitor the file
development.logwhile you are developing - each SQL query that Rails
executes will show up
there.  I believe (though you should double check this) that calling
comments.size when comments has not been loaded will do a single "select
count(*)..." query without instantiating a bunch of Comment objects.

-Steve Holder

On 9/19/06, joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> joevan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> > Hi,
> >
> > When writing a Rails app, what common tasks can likely result in
> > performance issues?
> >
> > The one I''m aware of is something like:
> > Model.find(:all).each do |elem|
> >   # do stuff
> > end
> >
> > Especially when there''s lots of elements in the Model.   
What other
> > ones are there?
> >
> > Also, does Rails do caching of queries?  If I''m in a view and
I do:
> > <% if user.admin? %> ...
> >
> > and then later on in that same view, I have the same code again, does
> > that execute two queries?
> >
> > Joe
>
> Another one:
> What''s a faster way to write:
>
> class User <  AR
>   has_many :comments
>   def number_of_comments
>     comments.size
>   end
> end
>
> (if I don''t want to do caching).  I assume that calling
> number_of_comments creates AR objects for each comment.
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi

the ruby Net::HTTP library allows calls like:

    Net::HTTP.get(url.path)

end similar looking post calls,
Since the RESTful support uses
DELETE and PUT, i was wondering how to make ruby calls
like the above Net::HTTP of the kind DELETE and PUT?

Thanks in advance!
Gustav

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Steve Holder wrote:
> Joe-
>
> You may find it useful to use "tail" to monitor the file
> development.logwhile you are developing - each SQL query that Rails
> executes will show up
> there.  I believe (though you should double check this) that calling
> comments.size when comments has not been loaded will do a single
"select
> count(*)..." query without instantiating a bunch of Comment objects.
I thought that, when in development mode, Rails generates different SQL
(i.e. more SQL queries) than when in production mode.

Is this not the case?

Joe
>
> On 9/19/06, joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >
> > joevan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> > > Hi,
> > >
> > > When writing a Rails app, what common tasks can likely result in
> > > performance issues?
> > >
> > > The one I''m aware of is something like:
> > > Model.find(:all).each do |elem|
> > >   # do stuff
> > > end
> > >
> > > Especially when there''s lots of elements in the Model.  
What other
> > > ones are there?
> > >
> > > Also, does Rails do caching of queries?  If I''m in a
view and I do:
> > > <% if user.admin? %> ...
> > >
> > > and then later on in that same view, I have the same code again,
does
> > > that execute two queries?
> > >
> > > Joe
> >
> > Another one:
> > What''s a faster way to write:
> >
> > class User <  AR
> >   has_many :comments
> >   def number_of_comments
> >     comments.size
> >   end
> > end
> >
> > (if I don''t want to do caching).  I assume that calling
> > number_of_comments creates AR objects for each comment.
> >
> >
> > >
> >
>
> ------=_Part_17129_27447126.1158682963475
> Content-Type: text/html; charset=ISO-8859-1
> X-Google-AttachSize: 1896
>
> Joe-<br><br>You may find it useful to use
&quot;tail&quot; to monitor the file development.log while you are
developing - each SQL query that Rails executes will show up there.&nbsp; I
believe (though you should double check this) that calling
> comments.size when comments has not been loaded will do a single
&quot;select count(*)...&quot; query without instantiating a bunch of
Comment objects.<br><br>-Steve
Holder<br><br><div><span
class="gmail_quote">On 9/19/06,
> <b class="gmail_sendername"><a
href="mailto:joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a></b>
&lt;<a
href="mailto:joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>&gt;
wrote:</span><blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt
0.8ex; padding-left: 1ex;">
> <br><a
href="mailto:joevan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org">joevan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org</a>
wrote:<br>&gt; Hi,<br>&gt;<br>&gt; When writing a
Rails app, what common tasks can likely result in<br>&gt; performance
issues?<br>&gt;<br>&gt; The one I''m aware of is
something like:
> <br>&gt; Model.find(:all).each do
|elem|<br>&gt;&nbsp;&nbsp; # do stuff<br>&gt;
end<br>&gt;<br>&gt; Especially when there''s lots of
elements in the Model.&nbsp;&nbsp;&nbsp;&nbsp;What
other<br>&gt; ones are there?<br>&gt;<br>&gt;
Also, does Rails do caching of queries?&nbsp;&nbsp;If I''m in a
view and I do:
> <br>&gt; &lt;% if user.admin? %&gt;
...<br>&gt;<br>&gt; and then later on in that same view, I
have the same code again, does<br>&gt; that execute two
queries?<br>&gt;<br>&gt; Joe<br><br>Another
one:<br>What''s a faster way to write:
> <br><br>class User
&lt;&nbsp;&nbsp;AR<br>&nbsp;&nbsp;has_many
:comments<br>&nbsp;&nbsp;def
number_of_comments<br>&nbsp;&nbsp;&nbsp;&nbsp;comments.size<br>&nbsp;&nbsp;end<br>end<br><br>(if
I don''t want to do caching).&nbsp;&nbsp;I assume that
calling<br>number_of_comments creates AR objects for each comment.
> <br><br><br></div><br>
> 
> ------=_Part_17129_27447126.1158682963475--

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Tuesday 19 September 2006 21:34,
joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Steve Holder wrote:
> > Joe-
> >
> > You may find it useful to use "tail" to monitor the file
> > development.logwhile you are developing - each SQL query that Rails
> > executes will show up
> > there.  I believe (though you should double check this) that
> > calling comments.size when comments has not been loaded will do a
> > single "select count(*)..." query without instantiating a
bunch of
> > Comment objects.
>
> I thought that, when in development mode, Rails generates different
> SQL (i.e. more SQL queries) than when in production mode.
>
> Is this not the case?
Definitely not. 

Regarding your original question, have a look at the :counter_cache 
option for associations.

Michael

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> Hi,
>
> When writing a Rails app, what common tasks can likely result in
> performance issues?
I found this article: http://www.infoq.com/articles/Rails-Performance

May be useful to others out there.

In my applications, the logs seem to indicate that the "rendering"
part, and not the "database" part, is the bottleneck.  Is ActiveRecord
work included in the database figure?

Another one: I''ve noticed that, if I have a couple thousand <%= ...
%>
on a page, it slows down considerably.  Would it be worth a try to
build up strings of html using <% str += "more" %> and then
<%= str %>?

Joe


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

if rendering is your bottleneck, you should check this out:
http://www.railsexpress.de/blog/articles/2006/08/15/rails-template-optimizer-beta-test

ed

On 9/19/06, joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> > Hi,
> >
> > When writing a Rails app, what common tasks can likely result in
> > performance issues?
>
> I found this article: http://www.infoq.com/articles/Rails-Performance
>
> May be useful to others out there.
>
> In my applications, the logs seem to indicate that the
"rendering"
> part, and not the "database" part, is the bottleneck.  Is
ActiveRecord
> work included in the database figure?
>
> Another one: I''ve noticed that, if I have a couple thousand <%=
... %>
> on a page, it slows down considerably.  Would it be worth a try to
> build up strings of html using <% str += "more" %> and then
<%= str %>?
>
> Joe
>
>
> >
>

-- 
Ed Hickey
Developer
Litmus Media
816-533-0409
ehickey-A4HEbNdjHgMmlAP/+Wk3EA@public.gmane.org
A Member of Think Partnership, Inc
www.ThinkPartnership.com
Amex ticker symbol: THK


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

joevandyk wrote:
> When writing a Rails app, what common tasks can likely result in
> performance issues?
I noticed in the Log folder that many SELECT statements had LIMIT 1 on
the end.

We all know that''s a no-no when you are _architecting_ a database.
It''s
mostly harmless when _using_ it...

...however, I would have relied on assertions demanding that all select
statements that only need 1 row return will only get 1 row. Without
LIMIT 1. That would imply that the database is sufficiently normal, and
the SELECT statements are sufficiently constrained.

So, in general, the ideal might be to transfer limit-checking to the
tests, so the code can run faster without it, and with proper
constraints.

(The spectre of SQL data normalization and query optimization also
raises it''s ugly head. We might presume that the slowest DB operation
is still faster than the fastest Ruby page rendering cycle, no? ;-)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---