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.
