Re: Performance optimization

[Martin Makundi]

Here is how I managed to do ajax refresh:

  final Component
newDummyAjaxUpdateComponentFromMarkup =
TakpPanelWithDynamicMarkup.newDummyAjaxUpdateComponentFromMarkup(freshMarkup,
markupId, false);
  if (newDummyAjaxUpdateComponentFromMarkup != null) {

target.addComponent(newDummyAjaxUpdateComponentFromMarkup);
  }


  public static Component newDummyAjaxUpdateComponentFromMarkup(String
freshMarkup, String markupId, boolean required) {
XmlPullParser xmlPullParser = new XmlPullParser();
try {
  xmlPullParser.parse(freshMarkup);
} catch (Exception e) {
  throw new RuntimeException(e);
}

XmlTag xmlTag = findStartTag(xmlPullParser, markupId);

if (xmlTag != null) {
  final StringBuilder stringBuilder = new StringBuilder();
  final int startEndPosition;
  {
final String tagAsString = xmlTag.toString();
stringBuilder.append(tagAsString);
startEndPosition = xmlTag.getPos() + tagAsString.length();
  }
  {
try {
  xmlTag = (XmlTag) xmlPullParser.nextTag();
} catch (Exception e) {
  if (required) {
throw new RuntimeException(e);
  }

  // else
  Utils.errorLog(TakpPanelWithDynamicMarkup.class, e);
}

stringBuilder.append(xmlPullParser.getInput(startEndPosition,
xmlTag.getPos())); // Value inside
stringBuilder.append(xmlTag.toString());
  }

  return new TakpPanelWithDynamicMarkup(markupId) {
private transient IResourceStream markupResourceStream;

@Override
public IResourceStream getMarkupResourceStream(MarkupContainer
container, Class containerClass) {
  if (markupResourceStream == null) {
final StringBufferResourceStream stream = new
StringBufferResourceStream();

stream.append("");

stream.append(stringBuilder);

stream.append("");

markupResourceStream = new MarkupResourceStream(stream);
  }

  return markupResourceStream;
}
  };
} else if (required) {
  throw new IllegalStateException("Component with markup id " +
markupId + " not found from markup stream " + freshMarkup);
}

return null;
  }


It could be streamlined ofcourse.. with duality it could be native
part of wicket ;)


**
Martin

2012/2/25 Per :
> Hi Martin,
>
> some of the things we did was (as mentioned by others) to generate HTML,
> this saved a lot of memory. But also to look really hard at the component
> tree and decide if everything was needed *all the time*. For instance, we
> had plenty of AJAX links that were rarely used (5 per row or so). We decided
> to make them load on demand only ("click for admin actions"). This saved
> some 500 bytes per row.  Also, some optimisations like replacing
> setVisible(false) by an empty component saved us some space. Some component
> use more memory than others, and can be replaced. Etc.  It's really crucial
> to use a profiler to see where all the bytes go. I wrote a blogpost over
> here:
> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
> a few months ago. You may even want to create your own eviction-policy that
> collects certain pages more aggressively than others (if applicable). Many
> options.
>
> But yeah, it's tough, it's one of the things I found most challenging about
> Wicket. I'd love to hear how you end solving with the problem, maybe there's
> something else to be learned!
>
> Good luck!
> Per
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Performance-optimization-tp4412659p4419111.html
> Sent from the Users forum mailing list archive at Nabble.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: Performance optimization

[Martin Makundi]

Sort of.. but it does not remain in the component tree and thus saves
some memroy. Is a markup.

**
Martin

2012/2/26 Igor Vaynberg :
> then its a panel
>
> -igor
>
> On Sat, Feb 25, 2012 at 4:44 PM, Martin Makundi
>  wrote:
>>> this is the same as add(new label("foo", new loadabledetachablemodel()
>>> { load() { return "markup" }}).setescapemdoelstrings(false))
>>
>> Is not completely same, because a MarkupResourceStreamProvider can
>> also provide markup for other components to land on.
>>
>> **
>> Martin
>>
>>>
>>> -igor
>>>
>>> On Sat, Feb 25, 2012 at 2:00 PM, Martin Makundi
>>>  wrote:
 Now that I am working with the markupresourcestream directly, I am
 beginning to think that Wicket should support dually both component
 hierarchy and markup hierarchy.

 Wicket chould have two kinds of add methods:

 add(Component c)

 add(String anchorId, MarkupResourceStreamProvider c)

 Such a MarkupResourceStreamProvider object could basically look same
 as a component (having setvisible,setenabled,addbehavior,etc.), but
 when it is added, its output would be injected to the parent's markup
 stream at anchor position (instead of a component being added to a
 component tree).

 The benefit would be, for a "stateless" component, its markup result
 could be automagically cached and the "component" itself that defined
 the markup, would not remain to waste any resources.

 Even better, the output of such a MarkupResourceStreamProvider should
 be logically a chain of "strings" alternating with possible IModels
 such that dynamic model values could be updated every time parent is
 re-rendered.


 Any comments?



 ..my2wildThughts..

 **
 Martin

 2012/2/25 Martin Makundi :
> Also
>
>   public IResourceStream getMarkupResourceStream(MarkupContainer
> container, Class containerClass) {
>
> seems quite feasible for making conditional markup.
>
> However, I must override
> MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
> IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
> for each component.
>
>
>
> **
> Martin
>
>
> 2012/2/25 Martin Makundi :
>> @Per about 
>> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
>>
>> You say "If condition A is met, show label A. If not, use
>> setVisible(false) to hide it. Combine that with Enclosures... Trouble
>> is, while the hidden component doesn't show up in the markup, it's
>> still part of the component tree! "
>>
>> I remember sometimes when using enclosures, I have rendered a page
>> which has not added some components inside an enclosure. Maybe there
>> could be a way to mark a region in the markup (like enclosure) where a
>> component can be optionally added.
>>
>> This way "setVisible=false" could be achieved simply by not adding
>> that component.
>>
>>
>>
>> **
>> Martin

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

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

Re: Performance optimization

[Igor Vaynberg]

then its a panel

-igor

On Sat, Feb 25, 2012 at 4:44 PM, Martin Makundi
 wrote:
>> this is the same as add(new label("foo", new loadabledetachablemodel()
>> { load() { return "markup" }}).setescapemdoelstrings(false))
>
> Is not completely same, because a MarkupResourceStreamProvider can
> also provide markup for other components to land on.
>
> **
> Martin
>
>>
>> -igor
>>
>> On Sat, Feb 25, 2012 at 2:00 PM, Martin Makundi
>>  wrote:
>>> Now that I am working with the markupresourcestream directly, I am
>>> beginning to think that Wicket should support dually both component
>>> hierarchy and markup hierarchy.
>>>
>>> Wicket chould have two kinds of add methods:
>>>
>>> add(Component c)
>>>
>>> add(String anchorId, MarkupResourceStreamProvider c)
>>>
>>> Such a MarkupResourceStreamProvider object could basically look same
>>> as a component (having setvisible,setenabled,addbehavior,etc.), but
>>> when it is added, its output would be injected to the parent's markup
>>> stream at anchor position (instead of a component being added to a
>>> component tree).
>>>
>>> The benefit would be, for a "stateless" component, its markup result
>>> could be automagically cached and the "component" itself that defined
>>> the markup, would not remain to waste any resources.
>>>
>>> Even better, the output of such a MarkupResourceStreamProvider should
>>> be logically a chain of "strings" alternating with possible IModels
>>> such that dynamic model values could be updated every time parent is
>>> re-rendered.
>>>
>>>
>>> Any comments?
>>>
>>>
>>>
>>> ..my2wildThughts..
>>>
>>> **
>>> Martin
>>>
>>> 2012/2/25 Martin Makundi :
 Also

   public IResourceStream getMarkupResourceStream(MarkupContainer
 container, Class containerClass) {

 seems quite feasible for making conditional markup.

 However, I must override
 MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
 IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
 for each component.



 **
 Martin


 2012/2/25 Martin Makundi :
> @Per about 
> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
>
> You say "If condition A is met, show label A. If not, use
> setVisible(false) to hide it. Combine that with Enclosures... Trouble
> is, while the hidden component doesn't show up in the markup, it's
> still part of the component tree! "
>
> I remember sometimes when using enclosures, I have rendered a page
> which has not added some components inside an enclosure. Maybe there
> could be a way to mark a region in the markup (like enclosure) where a
> component can be optionally added.
>
> This way "setVisible=false" could be achieved simply by not adding
> that component.
>
>
>
> **
> Martin
>>>
>>> -
>>> 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: Performance optimization

[Martin Makundi]

> this is the same as add(new label("foo", new loadabledetachablemodel()
> { load() { return "markup" }}).setescapemdoelstrings(false))

Is not completely same, because a MarkupResourceStreamProvider can
also provide markup for other components to land on.

**
Martin

>
> -igor
>
> On Sat, Feb 25, 2012 at 2:00 PM, Martin Makundi
>  wrote:
>> Now that I am working with the markupresourcestream directly, I am
>> beginning to think that Wicket should support dually both component
>> hierarchy and markup hierarchy.
>>
>> Wicket chould have two kinds of add methods:
>>
>> add(Component c)
>>
>> add(String anchorId, MarkupResourceStreamProvider c)
>>
>> Such a MarkupResourceStreamProvider object could basically look same
>> as a component (having setvisible,setenabled,addbehavior,etc.), but
>> when it is added, its output would be injected to the parent's markup
>> stream at anchor position (instead of a component being added to a
>> component tree).
>>
>> The benefit would be, for a "stateless" component, its markup result
>> could be automagically cached and the "component" itself that defined
>> the markup, would not remain to waste any resources.
>>
>> Even better, the output of such a MarkupResourceStreamProvider should
>> be logically a chain of "strings" alternating with possible IModels
>> such that dynamic model values could be updated every time parent is
>> re-rendered.
>>
>>
>> Any comments?
>>
>>
>>
>> ..my2wildThughts..
>>
>> **
>> Martin
>>
>> 2012/2/25 Martin Makundi :
>>> Also
>>>
>>>   public IResourceStream getMarkupResourceStream(MarkupContainer
>>> container, Class containerClass) {
>>>
>>> seems quite feasible for making conditional markup.
>>>
>>> However, I must override
>>> MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
>>> IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
>>> for each component.
>>>
>>>
>>>
>>> **
>>> Martin
>>>
>>>
>>> 2012/2/25 Martin Makundi :
 @Per about 
 http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

 You say "If condition A is met, show label A. If not, use
 setVisible(false) to hide it. Combine that with Enclosures... Trouble
 is, while the hidden component doesn't show up in the markup, it's
 still part of the component tree! "

 I remember sometimes when using enclosures, I have rendered a page
 which has not added some components inside an enclosure. Maybe there
 could be a way to mark a region in the markup (like enclosure) where a
 component can be optionally added.

 This way "setVisible=false" could be achieved simply by not adding
 that component.



 **
 Martin
>>
>> -
>> 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: Performance optimization

[Igor Vaynberg]

this is the same as add(new label("foo", new loadabledetachablemodel()
{ load() { return "markup" }}).setescapemdoelstrings(false))

-igor

On Sat, Feb 25, 2012 at 2:00 PM, Martin Makundi
 wrote:
> Now that I am working with the markupresourcestream directly, I am
> beginning to think that Wicket should support dually both component
> hierarchy and markup hierarchy.
>
> Wicket chould have two kinds of add methods:
>
> add(Component c)
>
> add(String anchorId, MarkupResourceStreamProvider c)
>
> Such a MarkupResourceStreamProvider object could basically look same
> as a component (having setvisible,setenabled,addbehavior,etc.), but
> when it is added, its output would be injected to the parent's markup
> stream at anchor position (instead of a component being added to a
> component tree).
>
> The benefit would be, for a "stateless" component, its markup result
> could be automagically cached and the "component" itself that defined
> the markup, would not remain to waste any resources.
>
> Even better, the output of such a MarkupResourceStreamProvider should
> be logically a chain of "strings" alternating with possible IModels
> such that dynamic model values could be updated every time parent is
> re-rendered.
>
>
> Any comments?
>
>
>
> ..my2wildThughts..
>
> **
> Martin
>
> 2012/2/25 Martin Makundi :
>> Also
>>
>>   public IResourceStream getMarkupResourceStream(MarkupContainer
>> container, Class containerClass) {
>>
>> seems quite feasible for making conditional markup.
>>
>> However, I must override
>> MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
>> IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
>> for each component.
>>
>>
>>
>> **
>> Martin
>>
>>
>> 2012/2/25 Martin Makundi :
>>> @Per about 
>>> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
>>>
>>> You say "If condition A is met, show label A. If not, use
>>> setVisible(false) to hide it. Combine that with Enclosures... Trouble
>>> is, while the hidden component doesn't show up in the markup, it's
>>> still part of the component tree! "
>>>
>>> I remember sometimes when using enclosures, I have rendered a page
>>> which has not added some components inside an enclosure. Maybe there
>>> could be a way to mark a region in the markup (like enclosure) where a
>>> component can be optionally added.
>>>
>>> This way "setVisible=false" could be achieved simply by not adding
>>> that component.
>>>
>>>
>>>
>>> **
>>> Martin
>
> -
> 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: Performance optimization

[Martin Makundi]

Now that I am working with the markupresourcestream directly, I am
beginning to think that Wicket should support dually both component
hierarchy and markup hierarchy.

Wicket chould have two kinds of add methods:

add(Component c)

add(String anchorId, MarkupResourceStreamProvider c)

Such a MarkupResourceStreamProvider object could basically look same
as a component (having setvisible,setenabled,addbehavior,etc.), but
when it is added, its output would be injected to the parent's markup
stream at anchor position (instead of a component being added to a
component tree).

The benefit would be, for a "stateless" component, its markup result
could be automagically cached and the "component" itself that defined
the markup, would not remain to waste any resources.

Even better, the output of such a MarkupResourceStreamProvider should
be logically a chain of "strings" alternating with possible IModels
such that dynamic model values could be updated every time parent is
re-rendered.


Any comments?



..my2wildThughts..

**
Martin

2012/2/25 Martin Makundi :
> Also
>
>   public IResourceStream getMarkupResourceStream(MarkupContainer
> container, Class containerClass) {
>
> seems quite feasible for making conditional markup.
>
> However, I must override
> MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
> IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
> for each component.
>
>
>
> **
> Martin
>
>
> 2012/2/25 Martin Makundi :
>> @Per about 
>> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
>>
>> You say "If condition A is met, show label A. If not, use
>> setVisible(false) to hide it. Combine that with Enclosures... Trouble
>> is, while the hidden component doesn't show up in the markup, it's
>> still part of the component tree! "
>>
>> I remember sometimes when using enclosures, I have rendered a page
>> which has not added some components inside an enclosure. Maybe there
>> could be a way to mark a region in the markup (like enclosure) where a
>> component can be optionally added.
>>
>> This way "setVisible=false" could be achieved simply by not adding
>> that component.
>>
>>
>>
>> **
>> Martin

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

Re: Performance optimization

[Martin Makundi]

Also

   public IResourceStream getMarkupResourceStream(MarkupContainer
container, Class containerClass) {

seems quite feasible for making conditional markup.

However, I must override
MarkupContainer.getAssociatedMarkupStream(enforceReload=true) and
IMarkupCacheKeyProvider.getCacheKey(==null) to get a different markup
for each component.



**
Martin


2012/2/25 Martin Makundi :
> @Per about 
> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size
>
> You say "If condition A is met, show label A. If not, use
> setVisible(false) to hide it. Combine that with Enclosures... Trouble
> is, while the hidden component doesn't show up in the markup, it's
> still part of the component tree! "
>
> I remember sometimes when using enclosures, I have rendered a page
> which has not added some components inside an enclosure. Maybe there
> could be a way to mark a region in the markup (like enclosure) where a
> component can be optionally added.
>
> This way "setVisible=false" could be achieved simply by not adding
> that component.
>
>
>
> **
> Martin

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

Re: Performance optimization

[Martin Makundi]

@Per about 
http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

You say "If condition A is met, show label A. If not, use
setVisible(false) to hide it. Combine that with Enclosures... Trouble
is, while the hidden component doesn't show up in the markup, it's
still part of the component tree! "

I remember sometimes when using enclosures, I have rendered a page
which has not added some components inside an enclosure. Maybe there
could be a way to mark a region in the markup (like enclosure) where a
component can be optionally added.

This way "setVisible=false" could be achieved simply by not adding
that component.



**
Martin

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

RE: Performance optimization

[Chris Colman]

The advice to try a different serializer is spot on.

Serialize any object tree to file using Java's standard serializer and
then open that file in a binary editor and then you'll see why the
standard Java serialization stream takes a surprisingly large amount of
bytes to store each object.

I had this problem in a desktop application years ago. We were pulling
in  .CSV files, converting each row to objects and then serializing the
lot. We were getting massive 15MB files from relatively small .CSV
files. For the majority of objects the header info stored for each
object in the stream is usually orders of magnitude larger than the
space taken up by the object's attributes.



>-Original Message-
>From: Per [mailto:p...@hamburg.de]
>Sent: Saturday, 25 February 2012 12:13 PM
>To: users@wicket.apache.org
>Subject: Re: Performance optimization
>
>
>Martin Makundi wrote
>>
>> The problem is that the SERIALIZATION takes time. So it does not help
to
>> ZIP AFTER serialization...
>>
>>
>
>Well, if you really only have one page in your session, and that page's
>serialisation is killing you, then you're right. But if you have
multiple
>page versions, and other pages in your session, and your session is
maybe
>even 50mb, then the zipping might help: not for this particular page,
but
>for all the *others* that also have to get read and restored.
>
>Also, have you considered trying other serialisers? I'm not an expert
on
>that topic, but I overheard other developers that there are faster
>libraries. They have tradeoffs, but maybe one of them works for you.
>
>Cheers,
>Per
>
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Performance-optimization-
>tp4412659p4419130.html
>Sent from the Users forum mailing list archive at Nabble.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: Performance optimization

[Martin Makundi]

@Per

>> I wrote a blogpost over here:
>> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

Did you try this approach:

> if the component is stateless you can autoadd it in onbeforerender(),
> such components are removed at the end of the request

?

**
Martin

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

Re: Performance optimization

[Martin Makundi]

> For instance, we
> had plenty of AJAX links that were rarely used (5 per row or so).
> We decided to make them load on demand only ("click for admin actions").

Yeah, we did this too.

> some of the things we did was (as mentioned by others) to generate HTML,
> this saved a lot of memory. But Also, some optimisations like replacing
> setVisible(false) by an empty component saved us some space.

Ok... this might be something to look at, because in our matrix most
of it is "empty" really, so there must be lots of invisible items.

> I wrote a blogpost over here:
> http://www.small-improvements.com/blog/technical/tuning-wicket-session-size

Great post, thanks!

> Well, if you really only have one page in your session, and that page's
> serialisation is killing you, then you're right. But if you have multiple
> page versions, and other pages in your session, and your session is maybe
> even 50mb, then the zipping might help: not for this particular page, but
> for all the *others* that also have to get read and restored.

We have already disabled versioning and page history ;) No back button
support... who really needs that ;)

> Also, have you considered trying other serialisers? I'm not an expert on
> that topic, but I overheard other developers that there are faster
> libraries. They have tradeoffs, but maybe one of them works for you.

I worry about maintenance overhead and possible bugs, the code is
alreay quite complex to add some "unknown variables" is not possible
at the moment.

**
Martin

> Cheers,
> Per
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Performance-optimization-tp4412659p4419130.html
> Sent from the Users forum mailing list archive at Nabble.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: Performance optimization

[Per]

Martin Makundi wrote
> 
> The problem is that the SERIALIZATION takes time. So it does not help to
> ZIP AFTER serialization...
> 
> 

Well, if you really only have one page in your session, and that page's
serialisation is killing you, then you're right. But if you have multiple
page versions, and other pages in your session, and your session is maybe
even 50mb, then the zipping might help: not for this particular page, but
for all the *others* that also have to get read and restored. 

Also, have you considered trying other serialisers? I'm not an expert on
that topic, but I overheard other developers that there are faster
libraries. They have tradeoffs, but maybe one of them works for you.
 
Cheers,
Per


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Performance-optimization-tp4412659p4419130.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Performance optimization

[Per]

Hi Martin,

some of the things we did was (as mentioned by others) to generate HTML,
this saved a lot of memory. But also to look really hard at the component
tree and decide if everything was needed *all the time*. For instance, we
had plenty of AJAX links that were rarely used (5 per row or so). We decided
to make them load on demand only ("click for admin actions"). This saved
some 500 bytes per row.  Also, some optimisations like replacing
setVisible(false) by an empty component saved us some space. Some component
use more memory than others, and can be replaced. Etc.  It's really crucial
to use a profiler to see where all the bytes go. I wrote a blogpost over
here:
http://www.small-improvements.com/blog/technical/tuning-wicket-session-size 
a few months ago. You may even want to create your own eviction-policy that
collects certain pages more aggressively than others (if applicable). Many
options. 

But yeah, it's tough, it's one of the things I found most challenging about
Wicket. I'd love to hear how you end solving with the problem, maybe there's
something else to be learned! 

Good luck!
Per


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Performance-optimization-tp4412659p4419111.html
Sent from the Users forum mailing list archive at Nabble.com.

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

RE: Performance optimization

[Chris Colman]

Native Java serialization is wy over the top in what is spits out to
the stream. Each object that gets streamed has it's entire class name
and package name dumped to the stream. So an object that might only have
a 4 byte integer attribute in it takes up to 100 or more bytes in the
stream.

You could make it much more efficient if you did your own streaming.

Regards,
Chris

>-Original Message-
>From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>Sent: Thursday, 23 February 2012 4:04 PM
>To: Bertrand Guay-Paquet
>Cc: users@wicket.apache.org
>Subject: Re: Performance optimization
>
>The problem is that the SERIALIZATION takes time. So it does not help
to
>ZIP AFTER serialization...
>
>I have debugged it and it's just thousands and thousands of components.
> Even printing the component paths alone take almost 10mb or more
because
>there is repetition ;)
>
>**
>Martin
>
>2012/2/23 Bertrand Guay-Paquet 
>
>> Hi,
>>
>> Have you seen the following thread?
>> http://apache-wicket.1842946.**n4.nabble.com/Shrinking-the-**
>> session-size-simply-by-**zipping-it-Saved-my-day-
>**td4402980.html<http://apache-wicket.1842946.n4.nabble.com/Shrinking-t
he-
>session-size-simply-by-zipping-it-Saved-my-day-td4402980.html>
>> Perhaps this can help you.
>>
>> That said, 10MB seems HUGE! Since you already use detachable models,
>maybe
>> you could have a look at a memory profiler like Java VisualVM to find
out
>> which objects take the most space.
>>
>> Bertrand
>>
>>
>> On 22/02/2012 10:12 PM, Martin Makundi wrote:
>>
>>> Hi!
>>>
>>> Any experiences how to optimize the performance of a Page that
>>> contains nested ListView:s with a total page serialized size of over
>>> 10 MB?
>>>
>>> I have made all actual data objects non-serializable and available
via
>>> loadabledetachablemodel, but page Serialization seems to kill the
>>> performance in ajax requests where I might be modifying just a
single
>>> cell in the maze.
>>>
>>> I tried callinc removeAll at onDetach... it improved performance but
>>> ofcourse event listeners don't work anymore ;) I could write custom
>>> event listeners as workaround, though, which would know to call
>>> onPopulate() before triggering an event.
>>>
>>> Any experiences of similar situation?
>>>
>>> **
>>> Martin
>>>
>>>
--**--**
>-
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgunsubscr...@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: Performance optimization

[Igor Vaynberg]

if the component is stateless you can autoadd it in onbeforerender(),
such components are removed at the end of the request

-igor

On Thu, Feb 23, 2012 at 11:09 AM, Martin Makundi
 wrote:
> I wonder if there could be components that would melt/dissolve after use...
>
> ... for example a label:
>
> container.add(new Label("xx"));
>
> After use, the label output would become part of container's markup
> output at proper position, but there would remain no reference to an
> instance of label component.
>
> This would be something like a "passive" component... not just "stateless".
>
> **
> Martin
>
> 2012/2/23 Igor Vaynberg :
>> ajax updates work based on components, so in this particular case you
>> would only be able to update the entire listview using ajax. so design
>> your component breakdown accordingly.
>>
>> of course if you design these optimized components to be able to
>> produce some part of its output you can use jquery ajax to repaint
>> just those parts...but thats a bit more wiring.
>>
>> -igor
>>
>> On Thu, Feb 23, 2012 at 8:43 AM, Martin Makundi
>>  wrote:
>>> Looks powerful, thanks. What about partial ajax updates, should I
>>> design so that I can replace complete webcomponents (might restrict
>>> optimization) or is there a way to interact nicely with wicket-ajax
>>> with such inline code?
>>>
>>> **
>>> Martin
>>>
>>> 2012/2/23 Igor Vaynberg :
 you can, for example, replace the entire listview with a single
 component like this:

 class workerlist extends webcomponent implements ilinklistener {

   oncomponenttagbody() {
         stringbuilder markup=new stringbuilder();
         markup.append("");
         for (worker:list) {
           
 markup.append("").append(Strings.escapeMarkup(worker.name())).append("");
           markup.append(">>> href=").append(urlfor(ilinklistener.interface)).append("&action=checkout>checkout
      ...
      replaceComponentTAgBody(, markup);
   }


   protected void onclick() {
       string action=getrequest().getparameter("action");
       switch (action) {}
    }
 }

 basically its kind of like writing a servlet, but within the scope of
 a component. not pretty but works.

 -igor

 On Thu, Feb 23, 2012 at 8:18 AM, Martin Makundi
  wrote:
>>> I think the best optimisation for this kind of thing is probably to try 
>>> to
>>> reduce the component count as much as possible by implementing custom
>>> components that render directly to html.
>>
>> +1
>
> What might be the best way (performance-wise) to make such a custom
> component (rendering the dynamic markup, for example replacing a
> label)? We have lots of labels and nested listview listitems...
>
> **
> Martin
>
>>
>
> -
> 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
>>
>
> -
> 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: Performance optimization

[Martin Makundi]

I wonder if there could be components that would melt/dissolve after use...

... for example a label:

container.add(new Label("xx"));

After use, the label output would become part of container's markup
output at proper position, but there would remain no reference to an
instance of label component.

This would be something like a "passive" component... not just "stateless".

**
Martin

2012/2/23 Igor Vaynberg :
> ajax updates work based on components, so in this particular case you
> would only be able to update the entire listview using ajax. so design
> your component breakdown accordingly.
>
> of course if you design these optimized components to be able to
> produce some part of its output you can use jquery ajax to repaint
> just those parts...but thats a bit more wiring.
>
> -igor
>
> On Thu, Feb 23, 2012 at 8:43 AM, Martin Makundi
>  wrote:
>> Looks powerful, thanks. What about partial ajax updates, should I
>> design so that I can replace complete webcomponents (might restrict
>> optimization) or is there a way to interact nicely with wicket-ajax
>> with such inline code?
>>
>> **
>> Martin
>>
>> 2012/2/23 Igor Vaynberg :
>>> you can, for example, replace the entire listview with a single
>>> component like this:
>>>
>>> class workerlist extends webcomponent implements ilinklistener {
>>>
>>>   oncomponenttagbody() {
>>>         stringbuilder markup=new stringbuilder();
>>>         markup.append("");
>>>         for (worker:list) {
>>>           
>>> markup.append("").append(Strings.escapeMarkup(worker.name())).append("");
>>>           markup.append(">> href=").append(urlfor(ilinklistener.interface)).append("&action=checkout>checkout
>>>      ...
>>>      replaceComponentTAgBody(, markup);
>>>   }
>>>
>>>
>>>   protected void onclick() {
>>>       string action=getrequest().getparameter("action");
>>>       switch (action) {}
>>>    }
>>> }
>>>
>>> basically its kind of like writing a servlet, but within the scope of
>>> a component. not pretty but works.
>>>
>>> -igor
>>>
>>> On Thu, Feb 23, 2012 at 8:18 AM, Martin Makundi
>>>  wrote:
>> I think the best optimisation for this kind of thing is probably to try 
>> to
>> reduce the component count as much as possible by implementing custom
>> components that render directly to html.
>
> +1

 What might be the best way (performance-wise) to make such a custom
 component (rendering the dynamic markup, for example replacing a
 label)? We have lots of labels and nested listview listitems...

 **
 Martin

>

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

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

Re: Performance optimization

[Igor Vaynberg]

ajax updates work based on components, so in this particular case you
would only be able to update the entire listview using ajax. so design
your component breakdown accordingly.

of course if you design these optimized components to be able to
produce some part of its output you can use jquery ajax to repaint
just those parts...but thats a bit more wiring.

-igor

On Thu, Feb 23, 2012 at 8:43 AM, Martin Makundi
 wrote:
> Looks powerful, thanks. What about partial ajax updates, should I
> design so that I can replace complete webcomponents (might restrict
> optimization) or is there a way to interact nicely with wicket-ajax
> with such inline code?
>
> **
> Martin
>
> 2012/2/23 Igor Vaynberg :
>> you can, for example, replace the entire listview with a single
>> component like this:
>>
>> class workerlist extends webcomponent implements ilinklistener {
>>
>>   oncomponenttagbody() {
>>         stringbuilder markup=new stringbuilder();
>>         markup.append("");
>>         for (worker:list) {
>>           
>> markup.append("").append(Strings.escapeMarkup(worker.name())).append("");
>>           markup.append("> href=").append(urlfor(ilinklistener.interface)).append("&action=checkout>checkout
>>      ...
>>      replaceComponentTAgBody(, markup);
>>   }
>>
>>
>>   protected void onclick() {
>>       string action=getrequest().getparameter("action");
>>       switch (action) {}
>>    }
>> }
>>
>> basically its kind of like writing a servlet, but within the scope of
>> a component. not pretty but works.
>>
>> -igor
>>
>> On Thu, Feb 23, 2012 at 8:18 AM, Martin Makundi
>>  wrote:
> I think the best optimisation for this kind of thing is probably to try to
> reduce the component count as much as possible by implementing custom
> components that render directly to html.

 +1
>>>
>>> What might be the best way (performance-wise) to make such a custom
>>> component (rendering the dynamic markup, for example replacing a
>>> label)? We have lots of labels and nested listview listitems...
>>>
>>> **
>>> Martin
>>>

>>>
>>> -
>>> 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: Performance optimization

[Martin Makundi]

Looks powerful, thanks. What about partial ajax updates, should I
design so that I can replace complete webcomponents (might restrict
optimization) or is there a way to interact nicely with wicket-ajax
with such inline code?

**
Martin

2012/2/23 Igor Vaynberg :
> you can, for example, replace the entire listview with a single
> component like this:
>
> class workerlist extends webcomponent implements ilinklistener {
>
>   oncomponenttagbody() {
>         stringbuilder markup=new stringbuilder();
>         markup.append("");
>         for (worker:list) {
>           
> markup.append("").append(Strings.escapeMarkup(worker.name())).append("");
>           markup.append(" href=").append(urlfor(ilinklistener.interface)).append("&action=checkout>checkout
>      ...
>      replaceComponentTAgBody(, markup);
>   }
>
>
>   protected void onclick() {
>       string action=getrequest().getparameter("action");
>       switch (action) {}
>    }
> }
>
> basically its kind of like writing a servlet, but within the scope of
> a component. not pretty but works.
>
> -igor
>
> On Thu, Feb 23, 2012 at 8:18 AM, Martin Makundi
>  wrote:
 I think the best optimisation for this kind of thing is probably to try to
 reduce the component count as much as possible by implementing custom
 components that render directly to html.
>>>
>>> +1
>>
>> What might be the best way (performance-wise) to make such a custom
>> component (rendering the dynamic markup, for example replacing a
>> label)? We have lots of labels and nested listview listitems...
>>
>> **
>> Martin
>>
>>>
>>
>> -
>> 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: Performance optimization

[Igor Vaynberg]

you can, for example, replace the entire listview with a single
component like this:

class workerlist extends webcomponent implements ilinklistener {

   oncomponenttagbody() {
 stringbuilder markup=new stringbuilder();
 markup.append("");
 for (worker:list) {
   
markup.append("").append(Strings.escapeMarkup(worker.name())).append("");
   markup.append("checkout
  ...
  replaceComponentTAgBody(, markup);
   }


   protected void onclick() {
   string action=getrequest().getparameter("action");
   switch (action) {}
}
}

basically its kind of like writing a servlet, but within the scope of
a component. not pretty but works.

-igor

On Thu, Feb 23, 2012 at 8:18 AM, Martin Makundi
 wrote:
>>> I think the best optimisation for this kind of thing is probably to try to
>>> reduce the component count as much as possible by implementing custom
>>> components that render directly to html.
>>
>> +1
>
> What might be the best way (performance-wise) to make such a custom
> component (rendering the dynamic markup, for example replacing a
> label)? We have lots of labels and nested listview listitems...
>
> **
> Martin
>
>>
>
> -
> 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: Performance optimization

[Martin Makundi]

>> I think the best optimisation for this kind of thing is probably to try to
>> reduce the component count as much as possible by implementing custom
>> components that render directly to html.
>
> +1

What might be the best way (performance-wise) to make such a custom
component (rendering the dynamic markup, for example replacing a
label)? We have lots of labels and nested listview listitems...

**
Martin

>

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

Re: Performance optimization

[Igor Vaynberg]

On Thu, Feb 23, 2012 at 7:26 AM, Thomas Matthijs  wrote:
> On Thu, Feb 23, 2012 at 4:12 AM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> Hi!
>>
>> Any experiences how to optimize the performance of a Page that
>> contains nested ListView:s with a total page serialized size of over
>> 10 MB?
>>
>> I have made all actual data objects non-serializable and available via
>> loadabledetachablemodel, but page Serialization seems to kill the
>> performance in ajax requests where I might be modifying just a single
>> cell in the maze.
>>
>> I tried callinc removeAll at onDetach... it improved performance but
>> ofcourse event listeners don't work anymore ;) I could write custom
>> event listeners as workaround, though, which would know to call
>> onPopulate() before triggering an event.
>>
>> Any experiences of similar situation?
>>
>
> I think the best optimisation for this kind of thing is probably to try to
> reduce the component count as much as possible by implementing custom
> components that render directly to html.

+1

-igor

>
> For example the CheckBoxMultipleChoice component can be implemented using a
> container and a CheckBox + Label component for every option, whereas the
> CheckBoxMultipleChoice is a single component that generates the html for
> the entire thing. You can probably find some parts of your component tree
> you can optimise this way.
>
> mvg,

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

Re: Performance optimization

[Martin Makundi]

Thanks, I will try to wave my magic wand and see what happens ...

2012/2/23 Bertrand Guay-Paquet :
> Even if it is asynchronous, it uses up some of the total IO capacity of the
> server. Reading the bytes back when the page is requested again is however a
> synchronous operation and it depends on IO.
>
> Anyway, if profiling shows that the slow part is the serialize call, then
> zipping won't help.
>
> If all else fails, you can also write custom components that generate the
> HTML of each table row directly instead of using thousands of labels.
>
>
> On 23/02/2012 10:05 AM, Martin Grigorov wrote:
>>
>> On Thu, Feb 23, 2012 at 3:55 PM, Bertrand Guay-Paquet
>>   wrote:
>>>
>>> First of all, you stated that your problem what that the serialized size
>>> was
>>> too big, so please don't be so rude.
>>>
>>> Now, are you sure that the slow part of serialization is not the IO for
>>> storing that 10MB? If it is, zipping the page could definitely improve
>>> performance, even if it takes a some CPU time to do the operation.
>>
>> Storing of the bytes in the disk is asynchronous by default.
>>
>>> Bertrand
>>>
>>>
>>> On 23/02/2012 12:04 AM, Martin Makundi wrote:

 The problem is that the SERIALIZATION takes time. So it does not help to
 ZIP AFTER serialization...
 I have debugged it and it's just thousands and thousands of components.
  Even printing the component paths alone take almost 10mb or more
 because
 there is repetition ;)
 **
 Martin

>>> -
>>> 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: Performance optimization

[Bertrand Guay-Paquet]

Even if it is asynchronous, it uses up some of the total IO capacity of 
the server. Reading the bytes back when the page is requested again is 
however a synchronous operation and it depends on IO.


Anyway, if profiling shows that the slow part is the serialize call, 
then zipping won't help.


If all else fails, you can also write custom components that generate 
the HTML of each table row directly instead of using thousands of labels.


On 23/02/2012 10:05 AM, Martin Grigorov wrote:

On Thu, Feb 23, 2012 at 3:55 PM, Bertrand Guay-Paquet
  wrote:

First of all, you stated that your problem what that the serialized size was
too big, so please don't be so rude.

Now, are you sure that the slow part of serialization is not the IO for
storing that 10MB? If it is, zipping the page could definitely improve
performance, even if it takes a some CPU time to do the operation.

Storing of the bytes in the disk is asynchronous by default.


Bertrand


On 23/02/2012 12:04 AM, Martin Makundi wrote:

The problem is that the SERIALIZATION takes time. So it does not help to
ZIP AFTER serialization...
I have debugged it and it's just thousands and thousands of components.
  Even printing the component paths alone take almost 10mb or more because
there is repetition ;)
**
Martin


-
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: Performance optimization

[Thomas Matthijs]

On Thu, Feb 23, 2012 at 4:12 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:

> Hi!
>
> Any experiences how to optimize the performance of a Page that
> contains nested ListView:s with a total page serialized size of over
> 10 MB?
>
> I have made all actual data objects non-serializable and available via
> loadabledetachablemodel, but page Serialization seems to kill the
> performance in ajax requests where I might be modifying just a single
> cell in the maze.
>
> I tried callinc removeAll at onDetach... it improved performance but
> ofcourse event listeners don't work anymore ;) I could write custom
> event listeners as workaround, though, which would know to call
> onPopulate() before triggering an event.
>
> Any experiences of similar situation?
>

I think the best optimisation for this kind of thing is probably to try to
reduce the component count as much as possible by implementing custom
components that render directly to html.

For example the CheckBoxMultipleChoice component can be implemented using a
container and a CheckBox + Label component for every option, whereas the
CheckBoxMultipleChoice is a single component that generates the html for
the entire thing. You can probably find some parts of your component tree
you can optimise this way.

mvg,

Re: Performance optimization

[Martin Grigorov]

On Thu, Feb 23, 2012 at 3:55 PM, Bertrand Guay-Paquet
 wrote:
> First of all, you stated that your problem what that the serialized size was
> too big, so please don't be so rude.
>
> Now, are you sure that the slow part of serialization is not the IO for
> storing that 10MB? If it is, zipping the page could definitely improve
> performance, even if it takes a some CPU time to do the operation.

Storing of the bytes in the disk is asynchronous by default.

>
> Bertrand
>
>
> On 23/02/2012 12:04 AM, Martin Makundi wrote:
>> The problem is that the SERIALIZATION takes time. So it does not help to
>> ZIP AFTER serialization...
>> I have debugged it and it's just thousands and thousands of components.
>>  Even printing the component paths alone take almost 10mb or more because
>> there is repetition ;)
>> **
>> Martin
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: Performance optimization

[Bertrand Guay-Paquet]

First of all, you stated that your problem what that the serialized size 
was too big, so please don't be so rude.


Now, are you sure that the slow part of serialization is not the IO for 
storing that 10MB? If it is, zipping the page could definitely improve 
performance, even if it takes a some CPU time to do the operation.


Bertrand

On 23/02/2012 12:04 AM, Martin Makundi wrote:
> The problem is that the SERIALIZATION takes time. So it does not help 
to ZIP AFTER serialization...
> I have debugged it and it's just thousands and thousands of 
components.  Even printing the component paths alone take almost 10mb or 
more because there is repetition ;)

> **
> Martin
>

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

Re: Performance optimization

[Martin Makundi]

>> You were right about 1.4 ;)
>>
>>> Question: If you don't serialize the page then how would you get it if
>>> it is not stored when the user presses browser back button ?
>>
>> Keep it in memory as it is.
>
> Your users have big monitors but your server has to have a lot of RAM too :-)

Is easier to buy more memory than serialization speed ;)

> In 1.5 it is quite easy to override each part of the serialization
> process, starting with IPageManager, to IPageStore, to IDataStore.
> Maybe it is time to upgrade.

Hehe... we have finally tweaked, poked and twingled 1.4 to work almost
bugfree... maybe I'll upgrade during my next vacation ;)


**
Martin

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

Re: Performance optimization

[Martin Grigorov]

On Thu, Feb 23, 2012 at 9:40 AM, Martin Makundi
 wrote:
>> Wicket 1.5: https://cwiki.apache.org/confluence/x/qIaoAQ
>> This explains how page storing works.
>
> You were right about 1.4 ;)
>
>> Question: If you don't serialize the page then how would you get it if
>> it is not stored when the user presses browser back button ?
>
> Keep it in memory as it is.
Your users have big monitors but your server has to have a lot of RAM too :-)

In 1.5 it is quite easy to override each part of the serialization
process, starting with IPageManager, to IPageStore, to IDataStore.
Maybe it is time to upgrade.

>
> **
> Martin
>
>>
>>>
>>> **
>>> Martin
>>>
>>> 2012/2/23 Bernard :
 If there are thousands of objects in a page then there is the question
 whether all of these objects actually represent state - state being
 the only reason why Wicket should serialize the page.

 In other words, is the page so complex that it requires 10MBytes to
 serialize itself in a manner that it can be re-created accurately from
 a stream. If yes then there is probably nothing you can do about it.

 If not then perhaps Wicket could be improved in that area. I would not
 be surprised if that was the case.

 Consider Java Swing desktop components. Swing has optimizations such
 as TableCellRenderer and TableCellEditor that are used as single
 instances to render cells for all rows in a column or more. If that
 makes sense in desktop applications with cheap memory and CPU then
 this makes even more sense on the server side. However, Wicket does
 NOT have such components and therefore really large lists are
 hopeless. There are things like IItemReuseStrategy but I cannot see
 how these would achieve the required efficiency.

 On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:

>I think that would be something that should be implemented at wicket
>core... anybody done this before?
>
>Is there any way to tell wicket NOT to serialize a page? For example
>give a timer if user does not invoke the page for 1 minutes it
>will not be serializeed..?
 [snip]

 -
 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
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: Performance optimization

[Martin Makundi]

> Wicket 1.5: https://cwiki.apache.org/confluence/x/qIaoAQ
> This explains how page storing works.

You were right about 1.4 ;)

> Question: If you don't serialize the page then how would you get it if
> it is not stored when the user presses browser back button ?

Keep it in memory as it is.

**
Martin

>
>>
>> **
>> Martin
>>
>> 2012/2/23 Bernard :
>>> If there are thousands of objects in a page then there is the question
>>> whether all of these objects actually represent state - state being
>>> the only reason why Wicket should serialize the page.
>>>
>>> In other words, is the page so complex that it requires 10MBytes to
>>> serialize itself in a manner that it can be re-created accurately from
>>> a stream. If yes then there is probably nothing you can do about it.
>>>
>>> If not then perhaps Wicket could be improved in that area. I would not
>>> be surprised if that was the case.
>>>
>>> Consider Java Swing desktop components. Swing has optimizations such
>>> as TableCellRenderer and TableCellEditor that are used as single
>>> instances to render cells for all rows in a column or more. If that
>>> makes sense in desktop applications with cheap memory and CPU then
>>> this makes even more sense on the server side. However, Wicket does
>>> NOT have such components and therefore really large lists are
>>> hopeless. There are things like IItemReuseStrategy but I cannot see
>>> how these would achieve the required efficiency.
>>>
>>> On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:
>>>
I think that would be something that should be implemented at wicket
core... anybody done this before?

Is there any way to tell wicket NOT to serialize a page? For example
give a timer if user does not invoke the page for 1 minutes it
will not be serializeed..?
>>> [snip]
>>>
>>> -
>>> 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
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.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: Performance optimization

[Martin Grigorov]

On Thu, Feb 23, 2012 at 9:14 AM, Martin Makundi
 wrote:
> Wicket page serialization is asynchronous.. I wonder if it would be
> possible to queue pages in a way that they are serialized only after a
> certain timeout and if they are visited during timeout they will be
> taken directly from queue...?

Wicket 1.5: https://cwiki.apache.org/confluence/x/qIaoAQ
This explains how page storing works.

Question: If you don't serialize the page then how would you get it if
it is not stored when the user presses browser back button ?

>
> **
> Martin
>
> 2012/2/23 Bernard :
>> If there are thousands of objects in a page then there is the question
>> whether all of these objects actually represent state - state being
>> the only reason why Wicket should serialize the page.
>>
>> In other words, is the page so complex that it requires 10MBytes to
>> serialize itself in a manner that it can be re-created accurately from
>> a stream. If yes then there is probably nothing you can do about it.
>>
>> If not then perhaps Wicket could be improved in that area. I would not
>> be surprised if that was the case.
>>
>> Consider Java Swing desktop components. Swing has optimizations such
>> as TableCellRenderer and TableCellEditor that are used as single
>> instances to render cells for all rows in a column or more. If that
>> makes sense in desktop applications with cheap memory and CPU then
>> this makes even more sense on the server side. However, Wicket does
>> NOT have such components and therefore really large lists are
>> hopeless. There are things like IItemReuseStrategy but I cannot see
>> how these would achieve the required efficiency.
>>
>> On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:
>>
>>>I think that would be something that should be implemented at wicket
>>>core... anybody done this before?
>>>
>>>Is there any way to tell wicket NOT to serialize a page? For example
>>>give a timer if user does not invoke the page for 1 minutes it
>>>will not be serializeed..?
>> [snip]
>>
>> -
>> 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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: Performance optimization

[Martin Makundi]

Wicket page serialization is asynchronous.. I wonder if it would be
possible to queue pages in a way that they are serialized only after a
certain timeout and if they are visited during timeout they will be
taken directly from queue...?

**
Martin

2012/2/23 Bernard :
> If there are thousands of objects in a page then there is the question
> whether all of these objects actually represent state - state being
> the only reason why Wicket should serialize the page.
>
> In other words, is the page so complex that it requires 10MBytes to
> serialize itself in a manner that it can be re-created accurately from
> a stream. If yes then there is probably nothing you can do about it.
>
> If not then perhaps Wicket could be improved in that area. I would not
> be surprised if that was the case.
>
> Consider Java Swing desktop components. Swing has optimizations such
> as TableCellRenderer and TableCellEditor that are used as single
> instances to render cells for all rows in a column or more. If that
> makes sense in desktop applications with cheap memory and CPU then
> this makes even more sense on the server side. However, Wicket does
> NOT have such components and therefore really large lists are
> hopeless. There are things like IItemReuseStrategy but I cannot see
> how these would achieve the required efficiency.
>
> On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:
>
>>I think that would be something that should be implemented at wicket
>>core... anybody done this before?
>>
>>Is there any way to tell wicket NOT to serialize a page? For example
>>give a timer if user does not invoke the page for 1 minutes it
>>will not be serializeed..?
> [snip]
>
> -
> 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: Performance optimization

[Bernard]

If there are thousands of objects in a page then there is the question
whether all of these objects actually represent state - state being
the only reason why Wicket should serialize the page.

In other words, is the page so complex that it requires 10MBytes to
serialize itself in a manner that it can be re-created accurately from
a stream. If yes then there is probably nothing you can do about it.

If not then perhaps Wicket could be improved in that area. I would not
be surprised if that was the case.

Consider Java Swing desktop components. Swing has optimizations such
as TableCellRenderer and TableCellEditor that are used as single
instances to render cells for all rows in a column or more. If that
makes sense in desktop applications with cheap memory and CPU then
this makes even more sense on the server side. However, Wicket does
NOT have such components and therefore really large lists are
hopeless. There are things like IItemReuseStrategy but I cannot see
how these would achieve the required efficiency.

On Thu, 23 Feb 2012 09:06:42 +0200, you wrote:

>I think that would be something that should be implemented at wicket
>core... anybody done this before?
>
>Is there any way to tell wicket NOT to serialize a page? For example
>give a timer if user does not invoke the page for 1 minutes it
>will not be serializeed..?
[snip]

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

Re: Performance optimization

[Martin Makundi]

Hi!

> But adding thousands of small components will still produce a big page...
>
> Suggestions:
>
> - show less items per page.
> Who wants to scroll a page with thousands items ?! Use paging and filters.

Is not an option. Our users fiddle with workshifts and they want to
see everything on one page... they have huge monitors

> - experiment with Jolira's stateless ajax behaviors
> By making your page stateless it wont be serialized at all (this
> answers your question about "tell Wicket to not serialize")

Hmm.. any link to this?

Challenge is that there will be for example "row updates" so I would
need to reconstruct the state somehow anyways.

**
Martin

>
> HTH
>
> On Thu, Feb 23, 2012 at 8:07 AM, Martin Makundi
>  wrote:
>> (ofcourse I mean invoke within 1 minute...)
>>
>> 2012/2/23 Martin Makundi :
>>> I think that would be something that should be implemented at wicket
>>> core... anybody done this before?
>>>
>>> Is there any way to tell wicket NOT to serialize a page? For example
>>> give a timer if user does not invoke the page for 1 minutes it
>>> will not be serializeed..?
>>>
>>> **
>>> Martin
>>>
>>> 2012/2/23 Juha Syrjälä :
 Hi,

 I would guess that Wicket uses a normal Java built-in serializer by 
 default.

 Here are some benchmarks for different serializer implementations
 https://github.com/eishay/jvm-serializers/wiki/ . Java's built-in 
 serializer
 is not the fastest...

 --
 Juha Syrjälä


 On 02/23/2012 08:45 AM, Martin Makundi wrote:
>
> But is serializing wicket native components only.. I would assume
> wicket does it best.
>
> 2012/2/23 Juha Syrjälä:
>>
>> Hi,
>>
>> Wicket 1.5 has support for pluggable serializers via ISerializer
>> interface,
>> you could try to plug in different serializer implementations, for
>> example
>> this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
>> should make the serialization bit faster.
>>
>> --
>> Juha Syrjälä
>>
>>
>> On 02/23/2012 05:12 AM, Martin Makundi wrote:
>>>
>>>
>>> Hi!
>>>
>>> Any experiences how to optimize the performance of a Page that
>>> contains nested ListView:s with a total page serialized size of over
>>> 10 MB?
>>>
>>> I have made all actual data objects non-serializable and available via
>>> loadabledetachablemodel, but page Serialization seems to kill the
>>> performance in ajax requests where I might be modifying just a single
>>> cell in the maze.
>>>
>>> I tried callinc removeAll at onDetach... it improved performance but
>>> ofcourse event listeners don't work anymore ;) I could write custom
>>> event listeners as workaround, though, which would know to call
>>> onPopulate() before triggering an event.
>>>
>>> Any experiences of similar situation?
>>>
>>> **
>>> Martin
>>>
>>> -
>>> 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

>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.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: Performance optimization

[Martin Grigorov]

Hi,

Wicket 1.5 uses by default JavaSerializer (ISerializer impl based on
Java Serialization API) because it is tested well (in previous
versions of Wicket). It may be slower than other serialization
frameworks but it works well in all cases.
KryoSerializer is easy to use with Java objects and it is very easy to
optiimize it for specific classes but it is not that well test and
fail you in corner cases. And Kryo itself is actively developed at the
moment...

But ISerializer is in Wicket 1.5 (I think Makundi still use 1.4).

Wicket is optimized to have as small as possible components. If you
see optimization in any of them please file a ticket and we will
improve it.
But adding thousands of small components will still produce a big page...

Suggestions:

- show less items per page.
Who wants to scroll a page with thousands items ?! Use paging and filters.

- experiment with Jolira's stateless ajax behaviors
By making your page stateless it wont be serialized at all (this
answers your question about "tell Wicket to not serialize")

HTH

On Thu, Feb 23, 2012 at 8:07 AM, Martin Makundi
 wrote:
> (ofcourse I mean invoke within 1 minute...)
>
> 2012/2/23 Martin Makundi :
>> I think that would be something that should be implemented at wicket
>> core... anybody done this before?
>>
>> Is there any way to tell wicket NOT to serialize a page? For example
>> give a timer if user does not invoke the page for 1 minutes it
>> will not be serializeed..?
>>
>> **
>> Martin
>>
>> 2012/2/23 Juha Syrjälä :
>>> Hi,
>>>
>>> I would guess that Wicket uses a normal Java built-in serializer by default.
>>>
>>> Here are some benchmarks for different serializer implementations
>>> https://github.com/eishay/jvm-serializers/wiki/ . Java's built-in serializer
>>> is not the fastest...
>>>
>>> --
>>> Juha Syrjälä
>>>
>>>
>>> On 02/23/2012 08:45 AM, Martin Makundi wrote:

 But is serializing wicket native components only.. I would assume
 wicket does it best.

 2012/2/23 Juha Syrjälä:
>
> Hi,
>
> Wicket 1.5 has support for pluggable serializers via ISerializer
> interface,
> you could try to plug in different serializer implementations, for
> example
> this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
> should make the serialization bit faster.
>
> --
> Juha Syrjälä
>
>
> On 02/23/2012 05:12 AM, Martin Makundi wrote:
>>
>>
>> Hi!
>>
>> Any experiences how to optimize the performance of a Page that
>> contains nested ListView:s with a total page serialized size of over
>> 10 MB?
>>
>> I have made all actual data objects non-serializable and available via
>> loadabledetachablemodel, but page Serialization seems to kill the
>> performance in ajax requests where I might be modifying just a single
>> cell in the maze.
>>
>> I tried callinc removeAll at onDetach... it improved performance but
>> ofcourse event listeners don't work anymore ;) I could write custom
>> event listeners as workaround, though, which would know to call
>> onPopulate() before triggering an event.
>>
>> Any experiences of similar situation?
>>
>> **
>> Martin
>>
>> -
>> 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
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: Performance optimization

[Martin Makundi]

(ofcourse I mean invoke within 1 minute...)

2012/2/23 Martin Makundi :
> I think that would be something that should be implemented at wicket
> core... anybody done this before?
>
> Is there any way to tell wicket NOT to serialize a page? For example
> give a timer if user does not invoke the page for 1 minutes it
> will not be serializeed..?
>
> **
> Martin
>
> 2012/2/23 Juha Syrjälä :
>> Hi,
>>
>> I would guess that Wicket uses a normal Java built-in serializer by default.
>>
>> Here are some benchmarks for different serializer implementations
>> https://github.com/eishay/jvm-serializers/wiki/ . Java's built-in serializer
>> is not the fastest...
>>
>> --
>> Juha Syrjälä
>>
>>
>> On 02/23/2012 08:45 AM, Martin Makundi wrote:
>>>
>>> But is serializing wicket native components only.. I would assume
>>> wicket does it best.
>>>
>>> 2012/2/23 Juha Syrjälä:

 Hi,

 Wicket 1.5 has support for pluggable serializers via ISerializer
 interface,
 you could try to plug in different serializer implementations, for
 example
 this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
 should make the serialization bit faster.

 --
 Juha Syrjälä


 On 02/23/2012 05:12 AM, Martin Makundi wrote:
>
>
> Hi!
>
> Any experiences how to optimize the performance of a Page that
> contains nested ListView:s with a total page serialized size of over
> 10 MB?
>
> I have made all actual data objects non-serializable and available via
> loadabledetachablemodel, but page Serialization seems to kill the
> performance in ajax requests where I might be modifying just a single
> cell in the maze.
>
> I tried callinc removeAll at onDetach... it improved performance but
> ofcourse event listeners don't work anymore ;) I could write custom
> event listeners as workaround, though, which would know to call
> onPopulate() before triggering an event.
>
> Any experiences of similar situation?
>
> **
> Martin
>
> -
> 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
>>

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

Re: Performance optimization

[Martin Makundi]

I think that would be something that should be implemented at wicket
core... anybody done this before?

Is there any way to tell wicket NOT to serialize a page? For example
give a timer if user does not invoke the page for 1 minutes it
will not be serializeed..?

**
Martin

2012/2/23 Juha Syrjälä :
> Hi,
>
> I would guess that Wicket uses a normal Java built-in serializer by default.
>
> Here are some benchmarks for different serializer implementations
> https://github.com/eishay/jvm-serializers/wiki/ . Java's built-in serializer
> is not the fastest...
>
> --
> Juha Syrjälä
>
>
> On 02/23/2012 08:45 AM, Martin Makundi wrote:
>>
>> But is serializing wicket native components only.. I would assume
>> wicket does it best.
>>
>> 2012/2/23 Juha Syrjälä:
>>>
>>> Hi,
>>>
>>> Wicket 1.5 has support for pluggable serializers via ISerializer
>>> interface,
>>> you could try to plug in different serializer implementations, for
>>> example
>>> this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
>>> should make the serialization bit faster.
>>>
>>> --
>>> Juha Syrjälä
>>>
>>>
>>> On 02/23/2012 05:12 AM, Martin Makundi wrote:


 Hi!

 Any experiences how to optimize the performance of a Page that
 contains nested ListView:s with a total page serialized size of over
 10 MB?

 I have made all actual data objects non-serializable and available via
 loadabledetachablemodel, but page Serialization seems to kill the
 performance in ajax requests where I might be modifying just a single
 cell in the maze.

 I tried callinc removeAll at onDetach... it improved performance but
 ofcourse event listeners don't work anymore ;) I could write custom
 event listeners as workaround, though, which would know to call
 onPopulate() before triggering an event.

 Any experiences of similar situation?

 **
 Martin

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

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

Re: Performance optimization

[Juha Syrjälä]

Hi,

I would guess that Wicket uses a normal Java built-in serializer by default.

Here are some benchmarks for different serializer implementations
https://github.com/eishay/jvm-serializers/wiki/ . Java's built-in 
serializer is not the fastest...


--
Juha Syrjälä

On 02/23/2012 08:45 AM, Martin Makundi wrote:

But is serializing wicket native components only.. I would assume
wicket does it best.

2012/2/23 Juha Syrjälä:

Hi,

Wicket 1.5 has support for pluggable serializers via ISerializer interface,
you could try to plug in different serializer implementations, for example
this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
should make the serialization bit faster.

--
Juha Syrjälä


On 02/23/2012 05:12 AM, Martin Makundi wrote:


Hi!

Any experiences how to optimize the performance of a Page that
contains nested ListView:s with a total page serialized size of over
10 MB?

I have made all actual data objects non-serializable and available via
loadabledetachablemodel, but page Serialization seems to kill the
performance in ajax requests where I might be modifying just a single
cell in the maze.

I tried callinc removeAll at onDetach... it improved performance but
ofcourse event listeners don't work anymore ;) I could write custom
event listeners as workaround, though, which would know to call
onPopulate() before triggering an event.

Any experiences of similar situation?

**
Martin

-
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: Performance optimization

[Martin Makundi]

But is serializing wicket native components only.. I would assume
wicket does it best.

2012/2/23 Juha Syrjälä :
> Hi,
>
> Wicket 1.5 has support for pluggable serializers via ISerializer interface,
> you could try to plug in different serializer implementations, for example
> this one https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That
> should make the serialization bit faster.
>
> --
> Juha Syrjälä
>
>
> On 02/23/2012 05:12 AM, Martin Makundi wrote:
>>
>> Hi!
>>
>> Any experiences how to optimize the performance of a Page that
>> contains nested ListView:s with a total page serialized size of over
>> 10 MB?
>>
>> I have made all actual data objects non-serializable and available via
>> loadabledetachablemodel, but page Serialization seems to kill the
>> performance in ajax requests where I might be modifying just a single
>> cell in the maze.
>>
>> I tried callinc removeAll at onDetach... it improved performance but
>> ofcourse event listeners don't work anymore ;) I could write custom
>> event listeners as workaround, though, which would know to call
>> onPopulate() before triggering an event.
>>
>> Any experiences of similar situation?
>>
>> **
>> Martin
>>
>> -
>> 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: Performance optimization

[Juha Syrjälä]

Hi,

Wicket 1.5 has support for pluggable serializers via ISerializer 
interface, you could try to plug in different serializer 
implementations, for example this one 
https://github.com/wicketstuff/core/wiki/Kryo-Serializer . That should 
make the serialization bit faster.


--
Juha Syrjälä

On 02/23/2012 05:12 AM, Martin Makundi wrote:

Hi!

Any experiences how to optimize the performance of a Page that
contains nested ListView:s with a total page serialized size of over
10 MB?

I have made all actual data objects non-serializable and available via
loadabledetachablemodel, but page Serialization seems to kill the
performance in ajax requests where I might be modifying just a single
cell in the maze.

I tried callinc removeAll at onDetach... it improved performance but
ofcourse event listeners don't work anymore ;) I could write custom
event listeners as workaround, though, which would know to call
onPopulate() before triggering an event.

Any experiences of similar situation?

**
Martin

-
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: Performance optimization

[Martin Makundi]

The problem is that the SERIALIZATION takes time. So it does not help to
ZIP AFTER serialization...

I have debugged it and it's just thousands and thousands of components.
 Even printing the component paths alone take almost 10mb or more because
there is repetition ;)

**
Martin

2012/2/23 Bertrand Guay-Paquet 

> Hi,
>
> Have you seen the following thread?
> http://apache-wicket.1842946.**n4.nabble.com/Shrinking-the-**
> session-size-simply-by-**zipping-it-Saved-my-day-**td4402980.html
> Perhaps this can help you.
>
> That said, 10MB seems HUGE! Since you already use detachable models, maybe
> you could have a look at a memory profiler like Java VisualVM to find out
> which objects take the most space.
>
> Bertrand
>
>
> On 22/02/2012 10:12 PM, Martin Makundi wrote:
>
>> Hi!
>>
>> Any experiences how to optimize the performance of a Page that
>> contains nested ListView:s with a total page serialized size of over
>> 10 MB?
>>
>> I have made all actual data objects non-serializable and available via
>> loadabledetachablemodel, but page Serialization seems to kill the
>> performance in ajax requests where I might be modifying just a single
>> cell in the maze.
>>
>> I tried callinc removeAll at onDetach... it improved performance but
>> ofcourse event listeners don't work anymore ;) I could write custom
>> event listeners as workaround, though, which would know to call
>> onPopulate() before triggering an event.
>>
>> Any experiences of similar situation?
>>
>> **
>> Martin
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

Re: Performance optimization

[Bertrand Guay-Paquet]

Hi,

Have you seen the following thread?
http://apache-wicket.1842946.n4.nabble.com/Shrinking-the-session-size-simply-by-zipping-it-Saved-my-day-td4402980.html
Perhaps this can help you.

That said, 10MB seems HUGE! Since you already use detachable models, 
maybe you could have a look at a memory profiler like Java VisualVM to 
find out which objects take the most space.


Bertrand

On 22/02/2012 10:12 PM, Martin Makundi wrote:

Hi!

Any experiences how to optimize the performance of a Page that
contains nested ListView:s with a total page serialized size of over
10 MB?

I have made all actual data objects non-serializable and available via
loadabledetachablemodel, but page Serialization seems to kill the
performance in ajax requests where I might be modifying just a single
cell in the maze.

I tried callinc removeAll at onDetach... it improved performance but
ofcourse event listeners don't work anymore ;) I could write custom
event listeners as workaround, though, which would know to call
onPopulate() before triggering an event.

Any experiences of similar situation?

**
Martin

-
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