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
