For wicket keeping server state gives you more performance, except maybe the serialization penalty which is an overhead.
But if you have enough memory for your clients (the expense to scale out) it is way faster If you use bookmarkable/stateless pages then everything has to be constructed on the the server everytime. If those pages are huge you create a lot of garbage. Also if you push a lot of state to the client means that you use more bandwidth and that is way more expensive then memory/disk on the server. If a page is in memory in wicket and you press for example refresh. It is really really fast. there is almost no overhead what so ever. (except getting data in the detached models again) But this all depends greatly on what kind of framework you use. For example GWT gives you only client side state, yes that scales pretty good on that part. johan On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <[EMAIL PROTECTED]> wrote: > Hi Martijn, > > On 16 jul 2008, at 10:19, Martijn Dashorst wrote: > > It is exactly the opposite: keeping state serverside increases >> performance. It makes it more expensive to scale out, but that is >> about it. >> > Can you elaborate a bit on your first statement? You need a lot of > data-juggling for many clients, so I'd love to learn why it gives higher > performance at the server. > > In my opinion it depends on your use case, but in high-load environments > I'd suggest to keep the state at the client. Sessions stored server-side not > only make it more expensive to scale out, but you're going to hit the > performance ceiling much sooner than with sessions at the client. > > > Regards, > > Daan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
