Re: Performance optimization
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(wicket:panel);
stream.append(stringBuilder);
stream.append(/wicket:panel);
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 p...@hamburg.de:
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
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 martin.maku...@koodaripalvelut.com:
@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
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 martin.maku...@koodaripalvelut.com:
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 martin.maku...@koodaripalvelut.com:
@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
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
martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com:
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 martin.maku...@koodaripalvelut.com:
@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
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
martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com:
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 martin.maku...@koodaripalvelut.com:
@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
then its a panel
-igor
On Sat, Feb 25, 2012 at 4:44 PM, Martin Makundi
martin.maku...@koodaripalvelut.com 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
martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com:
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 martin.maku...@koodaripalvelut.com:
@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
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 igor.vaynb...@gmail.com:
then its a panel
-igor
On Sat, Feb 25, 2012 at 4:44 PM, Martin Makundi
martin.maku...@koodaripalvelut.com 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
martin.maku...@koodaripalvelut.com 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 martin.maku...@koodaripalvelut.com:
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 martin.maku...@koodaripalvelut.com:
@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
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
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
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 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
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
@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
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 martin.maku...@koodaripalvelut.com wrote: (ofcourse I mean invoke within 1 minute...) 2012/2/23 Martin Makundi martin.maku...@koodaripalvelut.com: 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ä juha.syrj...@gmail.com: 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äjuha.syrj...@gmail.com: 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
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
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 bht...@gmail.com: 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
On Thu, Feb 23, 2012 at 9:14 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 bht...@gmail.com: 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
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 bht...@gmail.com: 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
On Thu, Feb 23, 2012 at 9:40 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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 bht...@gmail.com: 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
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
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
On Thu, Feb 23, 2012 at 3:55 PM, Bertrand Guay-Paquet ber...@step.polymtl.ca 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
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
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 ber...@step.polymtl.ca 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
Thanks, I will try to wave my magic wand and see what happens ... 2012/2/23 Bertrand Guay-Paquet ber...@step.polymtl.ca: 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 ber...@step.polymtl.ca 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
On Thu, Feb 23, 2012 at 7:26 AM, Thomas Matthijs li...@selckin.be 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
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
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(table);
for (worker:list) {
markup.append(trtd).append(Strings.escapeMarkup(worker.name())).append(/td);
markup.append(tda
href=).append(urlfor(ilinklistener.interface)).append(action=checkoutcheckout/a/td
...
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
martin.maku...@koodaripalvelut.com 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
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 igor.vaynb...@gmail.com:
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(table);
for (worker:list) {
markup.append(trtd).append(Strings.escapeMarkup(worker.name())).append(/td);
markup.append(tda
href=).append(urlfor(ilinklistener.interface)).append(action=checkoutcheckout/a/td
...
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
martin.maku...@koodaripalvelut.com 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
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
martin.maku...@koodaripalvelut.com 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 igor.vaynb...@gmail.com:
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(table);
for (worker:list) {
markup.append(trtd).append(Strings.escapeMarkup(worker.name())).append(/td);
markup.append(tda
href=).append(urlfor(ilinklistener.interface)).append(action=checkoutcheckout/a/td
...
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
martin.maku...@koodaripalvelut.com 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
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 igor.vaynb...@gmail.com:
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
martin.maku...@koodaripalvelut.com 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 igor.vaynb...@gmail.com:
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(table);
for (worker:list) {
markup.append(trtd).append(Strings.escapeMarkup(worker.name())).append(/td);
markup.append(tda
href=).append(urlfor(ilinklistener.interface)).append(action=checkoutcheckout/a/td
...
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
martin.maku...@koodaripalvelut.com 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
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
martin.maku...@koodaripalvelut.com 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 igor.vaynb...@gmail.com:
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
martin.maku...@koodaripalvelut.com 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 igor.vaynb...@gmail.com:
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(table);
for (worker:list) {
markup.append(trtd).append(Strings.escapeMarkup(worker.name())).append(/td);
markup.append(tda
href=).append(urlfor(ilinklistener.interface)).append(action=checkoutcheckout/a/td
...
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
martin.maku...@koodaripalvelut.com 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
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 ber...@step.polymtl.ca 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.htmlhttp://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.orgusers- 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
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
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 ber...@step.polymtl.ca 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.htmlhttp://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.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Performance optimization
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
But is serializing wicket native components only.. I would assume wicket does it best. 2012/2/23 Juha Syrjälä juha.syrj...@gmail.com: 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
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äjuha.syrj...@gmail.com: 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
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ä juha.syrj...@gmail.com: 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äjuha.syrj...@gmail.com: 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
(ofcourse I mean invoke within 1 minute...) 2012/2/23 Martin Makundi martin.maku...@koodaripalvelut.com: 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ä juha.syrj...@gmail.com: 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äjuha.syrj...@gmail.com: 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
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 martin.maku...@koodaripalvelut.com wrote: (ofcourse I mean invoke within 1 minute...) 2012/2/23 Martin Makundi martin.maku...@koodaripalvelut.com: 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ä juha.syrj...@gmail.com: 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äjuha.syrj...@gmail.com: 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
