# Common performance issues **URL:** \ **Category:** Rails\ **Created:** [September 19, 2006, 6:10pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248 "2006-09-19T18:10:26Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 6:10pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/1 "2006-09-19T18:10:26Z")
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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 6:18pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/2 "2006-09-19T18:18:27Z")
removed\_email\_address@domain.invalid wrote: > 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. ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 6:30pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/3 "2006-09-19T18:30:28Z")
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 H. ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 9:41pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/4 "2006-09-19T21:41:01Z")
Steve H. 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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 10:09pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/5 "2006-09-19T22:09:04Z")
On Tuesday 19 September 2006 21:34, removed\_email\_address@domain.invalid wrote: > 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 S. [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://www.schuerig.de/michael/](http://www.schuerig.de/michael/) ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 10:55pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/6 "2006-09-19T22:55:10Z")
removed\_email\_address@domain.invalid wrote: > Hi, > > When writing a Rails app, what common tasks can likely result in > performance issues? I found this article: [A Look at Common Performance Problems in Rails](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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 20, 2006, 12:27am UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/7 "2006-09-20T00:27:20Z")
if rendering is your bottleneck, you should check this out: [http://www.railsexpress.de/blog/articles/2006/08/15/rails-template-optimizer-beta-test](http://www.railsexpress.de/blog/articles/2006/08/15/rails-template-optimizer-beta-test) ed On 9/19/06, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > May be useful to others out there. > > > – Ed Hickey Developer Litmus Media 816-533-0409 removed\_email\_address@domain.invalid A Member of Think Partnership, Inc [www.ThinkPartnership.com](http://www.ThinkPartnership.com) Amex ticker symbol: THK ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 19, 2006, 7:04pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/8 "2006-09-19T19:04:38Z")
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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [September 20, 2006, 1:54pm UTC](https://www.ruby-forum.com/t/common-performance-issues/69248/9 "2006-09-20T13:54:35Z")
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? 😉