Raphael, I dont know how to trace down at that level. All i can say is the time taken to generate the query might be the issue. Rendering wont cause the delay at all.
On Fri, Jul 13, 2012 at 11:05 AM, Raphael Sofaer <[email protected]> wrote: > Hi Vivek, > > On Fri, Jul 13, 2012 at 12:55 AM, Vivek Sampara <[email protected]> > wrote: > > Raphael , > > > > The only thing thats causing this delay is because of the query ( 250+ IN > > conditions ). I would normally write a def in the model and do the > > conditions part there. > > > > That query is a result of the include clause in the query for pipette > pulls, and it takes pretty much no time at all. There aren't any > conditions, everyone can see all of these records. Taking out the > include would just split that query up, and query itself is pretty > much instantaneous. Even instantiating 300 AR objects doesn't take a > second, let alone multiple seconds. When I do the query and print out > the objects and related objects in the console, it takes much less > than a second. I'm pretty sure that whatever is happening is > happening in the views. Can Hobo give me a per-partial (or Hobo > equivalent) breakdown of the time spent? > > > eg. in controller > > > > def index > > hobo_index > > @pipette_pulls = Pipette_pull.filtered(current_user) > > end > > > > And model > > > > def self.filtered(user) > > @pipette_pulls = Pipette_full.all > > > > #Write your conditions and filter the data through ruby and return the > > filtered ones > > return @pipette_fulls > > end > > > > > > On Fri, Jul 13, 2012 at 5:14 AM, Raphael Sofaer <[email protected]> > wrote: > >> > >> Hi Matt, Vivek, > >> > >> Here's some more information. The app is running in production mode, > >> although I'd like it to be a reasonable speed in dev mode also, for > >> development. Dev mode now is up to twice as slow. There's tons of free > >> memory and cpu on the machine. Rails and hobo versions: > >> rails (3.0.5) > >> hobo (1.3.0) > >> > >> I've set the log level to debug to get the queries for the particular > >> index page that I'm looking at, the class names aren't secret: > >> > >> Processing by PipettePullsController#index as HTML > >> PipettePull Load (1.0ms) SELECT `pipette_pulls`.* FROM > `pipette_pulls` > >> LIMIT 300 OFFSET 0 > >> SQL (0.6ms) SELECT COUNT(*) FROM `pipette_pulls` > >> CACHE (0.0ms) SELECT `pipette_pulls`.* FROM `pipette_pulls` LIMIT 300 > >> OFFSET 0 > >> StereotaxicInjection Load (15.1ms) SELECT `stereotaxic_injections`.* > >> FROM `stereotaxic_injections` WHERE > >> (`stereotaxic_injections`.pipette_pull_id IN (4,[snip, there are about > 250 > >> ids in here],303)) > >> TracerType Load (0.5ms) SELECT `tracer_types`.* FROM `tracer_types` > >> WHERE (`tracer_types`.`id` IN > >> > (6,7,8,10,17,9,11,12,16,24,18,28,27,26,19,21,22,20,23,29,30,33,31,32,34,35)) > >> CACHE (0.0ms) SELECT COUNT(*) FROM `pipette_pulls` > >> Rendered pipette_pulls/index.dryml (9238.8ms) > >> Completed 200 OK in 9371ms (Views: 9239.8ms | ActiveRecord: 17.2ms) > >> > >> The queries are insignificant in the total time, and it doesn't seem > like > >> there are any hidden relations being loaded. Here's the controller > code for > >> the action: > >> > >> hobo_model_controller > >> auto_actions :all > >> def index > >> hobo_index :per_page => 300, :include => {:stereotaxic_injections => > >> :tracer_type} > >> end > >> > >> I put the nested include in a couple days ago, which sped it up > >> marginally, and reduced drastically the number of queries. > >> I noticed that the model has a view_permitted?(field) method which just > >> returns true. I'm not sure if that's run for every user/model > combination, > >> would that be a big performance hit? > >> > >> Thanks again, > >> Raphael > >> > >> On Wednesday, July 11, 2012 5:59:30 PM UTC-4, Matt jones wrote: > >>> > >>> > >>> On Jul 11, 2012, at 5:45 PM, Raphael Sofaer wrote: > >>> > >>> > Hi Hobo users, > >>> > > >>> > I'm a developer with rails experience working at a neuroscience lab, > >>> > and we have a legacy hobo app which is ridiculously slow. Some of > our index > >>> > pages take 10 seconds to load. All the time is in view rendering, > >>> > effectively none in ActiveRecord. How can I figure out what's wrong > here? > >>> > Most of the places I would but benchmarking functions are wrapped up > in hobo > >>> > methods, so I'm not sure what to do. The slowest page uses > hobo_index in > >>> > the controller, and collection and table_plus in the dryml file. > Are those > >>> > a recipe for disaster? I don't think there's any page that has a > >>> > sub-second load time, though. > >>> > >>> The first thing I'd check is the server - is it running in production > >>> mode? The behavior you've described sounds a lot like the result of an > app > >>> running in development mode. Also check to see if the server is > overloaded > >>> (swapping, etc) as some of the old defaults for gems like Passenger > >>> specified an unreasonable number of processes for small machines. > >>> > >>> Note that some of the timing stuff (especially on older Rails) will not > >>> always give sensible results; for instance, a default index action > will only > >>> actually load records when they're used on the page, causing the view > to get > >>> charged most of AR's time as well. > >>> > >>> Ping me off-list if you'd like another set of eyes on the code. > >>> > >>> --Matt Jones > >>> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Hobo Users" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/hobousers/-/hjBnu6V8hsYJ. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/hobousers?hl=en. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Hobo Users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/hobousers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Hobo Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/hobousers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
