the recommended way to handle this would be to cache the data not the generated html
-igor On Fri, Mar 26, 2010 at 1:11 AM, Martin Sachs <sachs.mar...@gmail.com> wrote: > We have a lot of Repeating views, which containing a lot of components, > which also contains repeatingviews. > > To know would should be rendered, we load some hopefully small > (listsizes, objectbyId, ...) datas from DB in the constructor and/or in > onBeforeRender and in isVisible. You are right, this is not a > recommented way. Most of the time is database-loading and wicket has no > performance-problem for us. We profile our application and never found > wicket-components as hotspots. > > One reason for loading some data in contstructur or onBeforeRender is to > prevent creating huge hierarchies. This is faster than override > isVisible(), since isVisible would called more than one times. > > For our usecase the responsetime is much faster with HTML-Caching, > because the Database-calls are minimized. We save the time for creating > componentshierarchies (all three categories) with loading data. > > > Martin > > Jeremy Thomerson schrieb: >> >> On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs <sachs.mar...@gmail.com >> <mailto:sachs.mar...@gmail.com>> wrote: >> >> hi, >> >> we need caching of components, since the construction of huge >> hierarchies is not cheap. The rendering ist fast. We cache the >> rendered >> HTML of a hole component via a beheaviour and write them on the next >> requests into a Label (unescaped). So instead of creating the complete >> hierarchie on every request, we create a much smaller one. But you >> must >> check, that the cachable components are stateless. Also we have JQuery >> for client-effects in this components, this would also be cached. >> >> The performance is much better with that: approx. 10-50 times better: >> 100ms with cache (the response time is not much depending on count >> of users) >> vs >> 1500 ms without cache depending how many parallel user >> >> >> A 15x gain is a big statement to make. Can you please break this >> 1500ms down into at least the following categories: >> >> 1 - time in IModel#getObject() and all child calls of this (IOW, >> loading data) >> 2 - time in constructor of components (without loading data in the >> constructor - hopefully you're not doing this) >> 3 - time in rendering of components >> >> That would be a much better number to give other users. I have NEVER >> seen where creating / rendering components could take 1400ms - unless >> you're doing something wrong like database calls in your component >> constructors. So, I suspect that most of that 1400ms (I would guess >> at least 1250ms) is in your model loading. >> >> The only time I've seen (or seen proof of) the component hierarchy >> actually be the slow part of a Wicket page is if you were displaying a >> repeating view of some sort with thousands of rows and each row had a >> bunch of components in it - leading to tens of thousands of components >> being built in the hierarchy. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
