wood burning stoves 2.0*
The moose likes Other Application Frameworks and the fly likes Wicket in action - Sessions and performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Wicket in action - Sessions and performance" Watch "Wicket in action - Sessions and performance" New topic
Author

Wicket in action - Sessions and performance

Iván Párraga
Ranch Hand

Joined: Dec 02, 2007
Posts: 54
Hi,

I've heard that one "problem" with the Wicket framework is that it uses the session to store large amounts of info to keep the state of most renders... I was wondering how this can affect to the performance in a high concurrency environement (specially with respect to the amounts of memory that the J2EE web component must handle).

Cheers,

Iv�n


Iván Párraga García
SCWCD 5, SCJD, SCJP 5, MySQL 5 DBA
Martijn Dashorst
author
Ranch Hand

Joined: Jan 23, 2006
Posts: 58
Originally posted by Iv�n P�rraga:
Hi,

I've heard that one "problem" with the Wicket framework is that it uses the session to store large amounts of info to keep the state of most renders... I was wondering how this can affect to the performance in a high concurrency environement (specially with respect to the amounts of memory that the J2EE web component must handle).

Cheers,

Iv�n


The rumors of Wicket's extravagant session usage are grosly overrated. It is something that folks remember hearing from cocktail parties, without ever having looked at the actual product.

Yes, Wicket does use serverside memory. Is it much? it depends on your application, how you set up your code, etc. In my experience the second level cache for Hibernate takes up more memory than the Wicket specific items.

In Wicket in Action we provide you with the means to control how much memory you are using. The chapter on models (Chapter 4 in the book, #5 in the MEAP), has a section on using detachable models to save memory usage and to keep things fresh.

I advise you to read the freely available chapter 1 of Wicket in Action - it is great bathroom reading, and contains some explanation of the choices Wicket has made regarding server side state.
Eelco Hillenius
author
Ranch Hand

Joined: Apr 23, 2008
Posts: 37
Originally posted by Iv�n P�rraga:
Hi,

I've heard that one "problem" with the Wicket framework is that it uses the session to store large amounts of info to keep the state of most renders... I was wondering how this can affect to the performance in a high concurrency environement (specially with respect to the amounts of memory that the J2EE web component must handle).

Cheers,

Iv�n


Wicket stores state on the server. Whether that involves 'large amounts' is subjective. In my experience a session occupies anywhere between 15kb up to a 100kb per session at any given time. So take the upper limit of 100kb, that means you need 1 GB of RAM to support 10,000 concurrent sessions on a box. I don't think that's such a bad trade off for a programming model that can save you lots of time and maintenance hassle.

Note that with Wicket 1.3 and up, only the state of the 'current' page is kept in memory. Older pages are stored in a 'second level cache', which is by default a paging file in a temp directory.

There are several options for clustering. Terracotta is a nice one, regular session replication supported by many servlet containers works, and there is a project in wicket-stuff that provides a clustering config based on Jetty and Tribes that is optimized for Wicket.
 
 
subject: Wicket in action - Sessions and performance
 
Similar Threads
Could anybody pick me a good Compoent-based Framework?
Which is the hottest Java Technolgy?
* Welcome Martijn Dashorst & Eelco Hillenius
Bumper Sticker item requests
WA #1.....word association