It looks like you've done a great job of optimizing your database access. That's usually the first stumbling block in a Hobo application because it's so easy for Hobo to load things implicitly.
I've seen 10 second DRYML pages before, but I've never before seen a 10 second DRYML page with optimized database access. It does look like you've got a fairly large page, at least from the number of elements you're pulling from the database. FIrst question: is your use pattern amenable to caching? If your pages change infrequently compared to the number of times they're accessed, your best bet may be to set up caching and not worry about initial page render. There are some nice new cache tags in 1.4, but Rails-style fragment caching is pretty easy to do in 1.3. Unfortunately the profiling tools you asked for aren't available. One helpful tool is https://github.com/ddnexus/dryml-firemarker This will let you understand the hierarchy of tags that went into producing the page, and may give you an indication of where it would be helpful to try and flatten things out. For instance, if it is called a few hundred times, it might be worth replacing <view:name/> with <%= name %>. You'll lose a permission check and the overhead of a few function calls. Another example: if the page consists of a big table, it might provide a nice speed up by using the <tr:> parameter rather than column parameters. Finally, Matt offered to help -- take advantage of that offer. He probably has more experience with Hobo apps, even including Tom & myself at this point. cheers, Bryan On Thu, Jul 12, 2012 at 7:44 PM, 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.
