I've seen long actions like this before, and it was almost always data logic. For the 6 second action - can you share the entire dev log output? The most typically thing I've seen is loading of associations with the views.
eg: In the controller you may load 10 groups, but the in your views you iterate over the groups.users and then over the users.message (or something like that). If you do that in the view, it doesn't get counted towards your DB time. As someone above mentioned, RPM is indeed a good way to get a better look into what's taking so long. On Sep 22, 4:11 pm, Chris Mayan <chris.ma...@gmail.com> wrote: > So as a quick aside, if one was instead to see this: > > Completed in 4208ms (View: 115, DB: 159) > > Is that indicative that the controllers are where all the time is being > spent? > > And what if in another scenario: > > 30 units => Completed in 6183ms (View: 28, DB: 793) > > 10 units => Completed in 1909ms (View: 26, DB: 235) > > 4 units => Completed in 909ms (View: 27, DB: 130) > > At least the problem seems somewhat linear... > > Is this a case of controllers just doing too much calculations - and whats > the best way of gaining clarity on which method / loop is causing the > delay? > > (Note: web and db servers are being run on vm on a local network, and we're > still on rails 2.3.5) > > - Chris > > > > On Wed, Sep 22, 2010 at 2:23 PM, Mikel Lindsaar <raasd...@gmail.com> wrote: > > On 22/09/2010, at 2:13 PM, Steve Hoeksema wrote: > > > It has looped and nested views, plenty of form helpers and link_to. > > > > Looking in RPM no one particular method seems to be slow, it's just a > > > large number of small ones. > > > > Given it's an internal project for use by a handful of people > > > irregularly I'll just leave it be. > > > For an internal app, you can do a cheap cache by just turning on > > ActiveSupport caching, then using the in memory cache option. No need to go > > to memcached or a file system store. > > > Then just cache away the loop that gets hit the most by wrapping it in a > > cache 'key' do end block. > > > link_to tags rarely change and can also benefit from caching, especially if > > you can cache a few of them together. > > > And if you are careful with what you cache, then it won't be a huge drain > > on your system resources. > > > A few megabytes of cache in RAM is a small price to pay to increase the > > speed of your app an insane amount. > > > Mikel > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to rails-ocea...@googlegroups.com. > > To unsubscribe from this group, send email to > > rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
