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

Reply via email to