Re: Caching components

[Igor Vaynberg]

set the reuse strategy to one that reuses components. we ship one,
look for implementations of the interface

-igor

On Fri, Mar 26, 2010 at 5:57 PM,   wrote:
> Igor,
>
> I don't understand the optimal use of the different repeaters list
> views in different scenarios well enough yet, so I would be greateful
> if someone could provide a link for more documentation.
>
> As far as I understand, though, refreshingview.setreuseitemstrategy()
> is about re-using items - it is all about models.
>
> I am thinking about re-using the rendering component for ALL items in
> the collection. That would not require any strategy. And I would want
> this to work with database driven collections, so far I have used
> DataProvider with LDMs. What needs to be done to get re-used
> components in this scenario?
>
> Bernard
>
> On Fri, 26 Mar 2010 16:41:11 -0700, you wrote:
>
>>repeaters support this, see listview.setreuseitems() and
>>refreshingview.setreuseitemstrategy()
>>
>>-igor
>>
>>On Fri, Mar 26, 2010 at 1:50 PM,   wrote:
>>> 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  
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 > > 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
>
>
> --

Re: Caching components

[bht]

Igor,

I don't understand the optimal use of the different repeaters list
views in different scenarios well enough yet, so I would be greateful
if someone could provide a link for more documentation.

As far as I understand, though, refreshingview.setreuseitemstrategy()
is about re-using items - it is all about models.

I am thinking about re-using the rendering component for ALL items in
the collection. That would not require any strategy. And I would want
this to work with database driven collections, so far I have used
DataProvider with LDMs. What needs to be done to get re-used
components in this scenario?

Bernard

On Fri, 26 Mar 2010 16:41:11 -0700, you wrote:

>repeaters support this, see listview.setreuseitems() and
>refreshingview.setreuseitemstrategy()
>
>-igor
>
>On Fri, Mar 26, 2010 at 1:50 PM,   wrote:
>> 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  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  > 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 addi

Re: Caching components

[Igor Vaynberg]

repeaters support this, see listview.setreuseitems() and
refreshingview.setreuseitemstrategy()

-igor

On Fri, Mar 26, 2010 at 1:50 PM,   wrote:
> 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  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 >>> > 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
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[bht]

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  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 >> > 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

Re: Caching components

[Igor Vaynberg]

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  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 > > 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

Re: Caching components

[Martijn Dashorst]

I'd wrap the getModel().getObject() in accessor methods to hide the
fact that you do that. getContract() is so much more legible than
getModel().getObject()

Martijn

On Fri, Mar 26, 2010 at 10:59 AM, Martin Sachs  wrote:
> Yes we use LoadableDetachableModel. But we also do some times
> getModel().getObject() deeper in hierarchy inside the construction, to
> e.g. set the visibility of a panel or to create just the right panel,
> instead of creating e.g. ten panels and implement isVisible().
>
> Martin
>
>
> Jan Kriesten schrieb:
>> Hi Martin,
>>
>>
>>> 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.
>>>
>>
>> why are you loading data in the component at all? There is this nice
>> 'LoadableDetachableModel' which could/should wrap that...
>>
>> Best regards, --- Jan.
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[Martin Sachs]

Yes we use LoadableDetachableModel. But we also do some times
getModel().getObject() deeper in hierarchy inside the construction, to
e.g. set the visibility of a panel or to create just the right panel,
instead of creating e.g. ten panels and implement isVisible().

Martin
   

Jan Kriesten schrieb:
> Hi Martin,
>
>   
>> 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.
>> 
>
> why are you loading data in the component at all? There is this nice
> 'LoadableDetachableModel' which could/should wrap that...
>
> Best regards, --- Jan.
>
>
>   


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[Jan Kriesten]

Hi Martin,

> 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.

why are you loading data in the component at all? There is this nice
'LoadableDetachableModel' which could/should wrap that...

Best regards, --- Jan.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[Martin Sachs]

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  > 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

Re: Caching components

[Jeremy Thomerson]

On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs 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

Re: Caching components

[Antoine van Wel]

Maybe this will get you started

http://twenty-six-wicket-tricks.googlecode.com/svn/trunk/twenty-six-wicket-tricks/src/main/java/com/locke/library/web/panels/caching/CachingPanel.java

After reading Jeremy's reply I think this code suffers some thread-safeness
issues though.


Antoine


On Wed, Mar 24, 2010 at 2:23 PM, zkn  wrote:

> Thanks Martin!
>
> If possible can you please give a hint how to use behavior to cache the
> rendered HTML for a component?
>
> On 24.03.2010, at 10:26, Martin Sachs 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 users.
> >
> >
> > in near feature i will announce the site officially here.
> >
> > Martin
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Caching components

[zkn]

Thanks Martin!

If possible can you please give a hint how to use behavior to cache the 
rendered HTML for a component?

On 24.03.2010, at 10:26, Martin Sachs 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 users.
> 
> 
> in near feature i will announce the site officially here.
> 
> Martin


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[zkn]

On 24.03.2010, at 09:23, Jeremy Thomerson wrote:

> Components are not thread safe, and not intended to be used in this way -
> there would be a significant undertaking to make them cacheable, and the
> cost of the synchronization would likely far outweigh the current costs of
> component instantiation, etc...

I see this could be a problem especially for with Java 1.4. With concurrency 
packages in Java 1.5  I believe this could easily be made thread safe with 
almost no cost for synchronization.

> 
> Where you can make the biggest difference is caching your models.  If you
> don't have to re-retrieve your model data, then you can get huge gains.

Yes, but still keeping the rendered html for complex read-only components would 
be the fastest possible way.

> 
> Of course, if you thoroughly do your performance testing and find that your
> site really is so huge and has so much traffic that the extra instantiation
> is hurting you, the way to go is caching the generated markup with a
> frontend cache.

I was first considering this approach especially with bookmarkable urls this 
could become beautiful. But would Wicket really allow using frontend cache 
cause it relies on user's session to handle form submits, ajax actions etc...?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[Martin Sachs]

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 users.


in near feature i will announce the site officially here.

Martin


Jeremy Thomerson schrieb:
> Components are not thread safe, and not intended to be used in this way -
> there would be a significant undertaking to make them cacheable, and the
> cost of the synchronization would likely far outweigh the current costs of
> component instantiation, etc...
>
> Where you can make the biggest difference is caching your models.  If you
> don't have to re-retrieve your model data, then you can get huge gains.
>
> Of course, if you thoroughly do your performance testing and find that your
> site really is so huge and has so much traffic that the extra instantiation
> is hurting you, the way to go is caching the generated markup with a
> frontend cache.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Wed, Mar 24, 2010 at 2:15 AM, zkn  wrote:
>
>   
>> Hi,
>>
>> since Wicket uses session to store the components hierarchy for a page is
>> it possible to store parts of the hierarchy in the application context
>> instead of the user session? If it's not possible do you consider it worth
>> to add as feature request?
>>
>> What's the idea: imagine a home page of a website where eventually for a
>> short time of period( say 1 minute) the only dynamic component is a search
>> form( and that's only in case the user hits search). The rest of the page
>> consist of components that do not change for each user request - for example
>> a block of news. If 100 users hit the page simultaneously they will actually
>> see the same content in that block and there is nothing in that block that
>> depends on the user session. The content may change in few minutes when a
>> new article has been added.
>>
>> What if for example the developer has the option to make a component
>> cacheable by implementing specific interface which will give the developer
>> the option to use the cached version or render and possible store the new
>> rendered component in cache?
>>
>> Seems like this can significantly improve performance in certain
>> situations.
>>
>> Regards,
>> Ozkan
>> -
>> 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

Re: Caching components

[Jeremy Thomerson]

Components are not thread safe, and not intended to be used in this way -
there would be a significant undertaking to make them cacheable, and the
cost of the synchronization would likely far outweigh the current costs of
component instantiation, etc...

Where you can make the biggest difference is caching your models.  If you
don't have to re-retrieve your model data, then you can get huge gains.

Of course, if you thoroughly do your performance testing and find that your
site really is so huge and has so much traffic that the extra instantiation
is hurting you, the way to go is caching the generated markup with a
frontend cache.

--
Jeremy Thomerson
http://www.wickettraining.com



On Wed, Mar 24, 2010 at 2:15 AM, zkn  wrote:

> Hi,
>
> since Wicket uses session to store the components hierarchy for a page is
> it possible to store parts of the hierarchy in the application context
> instead of the user session? If it's not possible do you consider it worth
> to add as feature request?
>
> What's the idea: imagine a home page of a website where eventually for a
> short time of period( say 1 minute) the only dynamic component is a search
> form( and that's only in case the user hits search). The rest of the page
> consist of components that do not change for each user request - for example
> a block of news. If 100 users hit the page simultaneously they will actually
> see the same content in that block and there is nothing in that block that
> depends on the user session. The content may change in few minutes when a
> new article has been added.
>
> What if for example the developer has the option to make a component
> cacheable by implementing specific interface which will give the developer
> the option to use the cached version or render and possible store the new
> rendered component in cache?
>
> Seems like this can significantly improve performance in certain
> situations.
>
> Regards,
> Ozkan
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Caching components

[zkn]

Hi,

since Wicket uses session to store the components hierarchy for a page is it 
possible to store parts of the hierarchy in the application context instead of 
the user session? If it's not possible do you consider it worth to add as 
feature request?

What's the idea: imagine a home page of a website where eventually for a short 
time of period( say 1 minute) the only dynamic component is a search form( and 
that's only in case the user hits search). The rest of the page consist of 
components that do not change for each user request - for example a block of 
news. If 100 users hit the page simultaneously they will actually see the same 
content in that block and there is nothing in that block that depends on the 
user session. The content may change in few minutes when a new article has been 
added. 

What if for example the developer has the option to make a component cacheable 
by implementing specific interface which will give the developer the option to 
use the cached version or render and possible store the new rendered component 
in cache? 

Seems like this can significantly improve performance in certain situations.

Regards,
Ozkan
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching components

[Igor Vaynberg]

usually component render is cheap - it is the retrieval of model data
that drives the render that is expensive. so you should cache this
data rather then the component output.

-igor


On 8/5/07, Dariusz Wojtas <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Is it possible to cache some component output?
> Sometimes we know that some custom component output does not depend on the
> browser and changes very rarely. But generating it every time may be very
> costly.
>
> What is the background?
> I have a topMenu component, which depends on database, but does not change
> once started.
> Or I have a productCategories component, it requires several DB calls to
> render, but I would love to cache it's output per parentID as it does not
> change once rendered.
>
> Is there any way to tell the component to cache somewhere it's output? Some
> method that may be overriden and give rendering hint?
>
> Other question.
> What I can see in examples is that usually all components are added to a
> page in it's constructor.
> Is it allowed to use cached instances of components?
> Are they thread safe by default (if I do not break it myself)?
> Is it allowed to add a component instance to multiple other objects at the
> same time?
>
> I cannot find such info anywhere in wiki.
> Any hint in this area would be helpful.
>
> Regards
> Dariusz Wojtas
> --
> View this message in context: 
> http://www.nabble.com/Caching-components-tf4219802.html#a12004616
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Caching components

[Dariusz Wojtas]

Hi,

Is it possible to cache some component output?
Sometimes we know that some custom component output does not depend on the
browser and changes very rarely. But generating it every time may be very
costly.

What is the background?
I have a topMenu component, which depends on database, but does not change
once started.
Or I have a productCategories component, it requires several DB calls to
render, but I would love to cache it's output per parentID as it does not
change once rendered.

Is there any way to tell the component to cache somewhere it's output? Some
method that may be overriden and give rendering hint?

Other question.
What I can see in examples is that usually all components are added to a
page in it's constructor.
Is it allowed to use cached instances of components?
Are they thread safe by default (if I do not break it myself)?
Is it allowed to add a component instance to multiple other objects at the
same time?

I cannot find such info anywhere in wiki.
Any hint in this area would be helpful.

Regards
Dariusz Wojtas
-- 
View this message in context: 
http://www.nabble.com/Caching-components-tf4219802.html#a12004616
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]