But why in repeating views are the components duplicated for each row? Wicket should re-use the components - one instance for each row could do all the rendering. Not one instance for each row which is a waste.
Caching is a different concept as it also preserves the data which is not wanted in repeaters unless one wants to cache the whole collection. Bernard On Fri, 26 Mar 2010 06:50:24 -0700, you wrote: >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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
