On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <[EMAIL PROTECTED]> wrote: > 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.
What is this data juggling you talk of? If you use sticky sessions (which is really necessary for any serious web application IMO) there should not be any data juggling. > In my opinion it depends on your use case, but in high-load environments I'd > suggest to keep the state at the client. As long as you have 1 page that uses the server as an RPC service, this works. WHen you have to transfer state between different pages you'd rather keep the state on the server. Imagine posting 1MB of client side state to the server, and then sending it back (happened with a .net app). > 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. What performance ceiling are you talking about? There is no performance penalty for storing state on the server, as long as you don't have to synchronize it with other servers. Otherwise it is just using memory, and functions as a good cache. To minimize clustering overhead most folks choose sticky sessions with a buddy system for failover. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
