[Toaster] [review-request] V2: 6137 excessive load time for All Recipes page

[Reyna, David]

Hi Dave,

> If we split recipes into 1 html page per tab, ...

I think that you are referring to the Recipe Detail page (recipe.html). That page does have four tabs (implemented as "wells"), but it is very small and localized to a single recipe, so I do not see load delays.

The page I am referring to is the "All Recipes" page (recipes.html). It has no tabs. It does have a column for forward dependencies and a column for reverse dependencies per package, and that is where the load time comes from.

We can certainly consider reducing the default count from 100 to 25, but I think that my proposed speed up is applicable in all cases, especially if the user decides they really want to 100 line view for their own purposes.

- David


> -----Original Message-----
> From: Lerner, Dave
> Sent: Friday, April 11, 2014 7:20 AM
> To: BARROS PENA, BELEN; Reyna, David
> Cc: toaster at yoctoproject.org
> Subject: RE: [review-request] V2: 6137 excessive load time for All Recipes
> page
> 
> If we split recipes into 1 html page per tab, then the apparent delays will
> be split into a few seconds per tab switch, and probably less since the tab-
> specific queries can be optimized further using either the forward or reverse
> joins on package and package_dependency (for example for the package tab).
> 
> However, the greatest side effect of that change, 1 html page per tab, is
> simplicity in using other 'included' pages that define sorting and search
> bars without adding a lot of logic that tries to send the active #anchor from
> the client to the server in some encoded form, and then re-encode it back
> through our view functions to the client.
> 
> Also I feel strongly that the simplest solution is to switch to a default of
> 25 rows for this view.  Here's why: we have column sorting, and rows-per-page
> widgets, so I don't feel that the primary workflow will be perusing long
> lists, but rather filtering to find what you want, either by entering
> strings, sorting alphabetically, or sorting on size.
> 
> For that matter (an aside) if long list browsing must be supported, then
> there isn't a reason  to constrain that list to 100 rows - it should be a
> pull-down or input field with a max value on the order of 10^3 rows.
> 
> Dave
> > -----Original Message-----
> > From: Barros Pena, Belen [mailto:belen.barros.pena at intel.com]
> > Sent: Friday, April 11, 2014 7:41 AM
> > To: Reyna, David; Lerner, Dave
> > Cc: toaster at yoctoproject.org
> > Subject: Re: [review-request] V2: 6137 excessive load time for All Recipes
> page
> >
> > On 11/04/2014 01:44, "Reyna, David" <david.reyna at windriver.com> wrote:
> >
> > >Here are the timing results on my slow host for the rendering time:
> > >
> > >  (a) Original: 13 seconds
> > >  (b) V1      :  7 seconds
> > >  (c) V2      :  4 seconds
> >
> > This is obviously a huge improvement. What bothers me is that the Recipes
> > page still seems to be performing much worse than all other pages. Should
> > we be trying to fix the root cause of the problem, ie. the "100*(2+2)
> > foreign key lookups and filters/count"?
> >
> > Thanks!
> >
> > Belén
> >