Building scalable app with wicket

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Building scalable app with wicket

Tim Johnson-2
I'm looking for any recommendations for building an app that will be
scalable for large user loads (500+ concurrent) using Wicket.  I'm new to
the framework and in reading some of the FAQs, I'm concerned that Wicket is
not right for me.

The app will need to store state and have the ability to bookmark and page
with state.


Thanks for any advice

Tim



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wicket-user
Reply | Threaded
Open this post in threaded view
|

Re: Building scalable app with wicket

Igor Vaynberg-2
my recomendation would to be to start working with the HEAD version. it offers a lot of improvements on 1.1 that make life easier

mainly

page url mounting: which give you nice looking stateful urls that can be bookmarked (see niceurl example in wicket-examples)

IPageSource that lets you customize exactly how much state a page keeps in a session (read javadoc for details)

IPageMapEvictionStrategy lets you customize how many pages and which are kept in session (read javadoc for details)

there is a lot of fud about wicket and clustered environments. a lot of it, imho, comes from the fact that with mvc frameworks session space is difficult to use well and mvc frameworks are what people are used to. wicket stores things in session automatically so they are only kept for as long as they are needed, and cleaned up for you when the are not.

wicket is the opposite of mvc as far as session space management. mvcs are by default zero-session state while wicket by default is heavy on session state. at its base its really a cpu/memory trade off - the more you store in session the less cpu it takes to re-render a page, and vice versa. its much easier to upgrade memory then it is cpu power imho.

the only time session size is really a concren is if you are replicating the session across the nodes of the cluster.

first, do you need to do this? this depends on how users use your app ( if a node im on crashes do i lose 5 minutes of work or 3 hours? )
second, does your servlet container replicate the whole session or only the attributes that changed (which is much more efficient) ?
third, are you replicating your session to all the nodes in a cluster? or does each cluster have one backup-buddy.
how fat is the backplane comm channel?

i guess what i am getting at is that session replication is a concern for certain cluster setups while not a large concern for others. your mileage may vary.

i wish i had some concrete statistics to show, but i do not yet. when i finish my current project i will have a very large set of real pages to gather statistics from.

-Igor


On 12/30/05, Tim Johnson <[hidden email]> wrote:
I'm looking for any recommendations for building an app that will be
scalable for large user loads (500+ concurrent) using Wicket.  I'm new to
the framework and in reading some of the FAQs, I'm concerned that Wicket is
not right for me.

The app will need to store state and have the ability to bookmark and page
with state.


Thanks for any advice

Tim



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wicket-user