On 16 jul 2008, at 11:34, Martijn Dashorst wrote:
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.
But if you need failover, you need a buddy system, because session
sharing across multiple clusters is not that desirable or fast. You
eliminate the necessary data-juggling by using an inferior way of
failover. Because you need more memory and more processing power and
LAN traffic to keep the state synchronized, you simply need more iron
to serve your web application. So, you need to scale out to larger
clusters earlier. It's cheaper and faster to keep the state at the
client.
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).
So don't use multiple pages. Make your applications without complete
page refreshes. Replace parts of your functionality, like panel
replacing in Wicket. When you've fetched that panel once, cache it at
the client (if done right, browsers do this for you automatically).
The server thus only gives data or (static) JS/HTML. Transfer client-
fetched data in a format like JSON, which is easily compressed and can
be fetched stateless. The server just 'dumbly' returns data, much like
a session-less DB-server. It's even possible to aggressively cache
these responses in the browser, on downstream servers and/or on the
server.
This is exactly what GMail does, after your initial session. It seems
to work for them... :-) GMail is one of the snappiest web apps out
there. Google does complete page refreshes, but probably only because
it is 90% search result data. Full page refreshes can also be cached,
but only if they're stateless.
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.
As long as you don't have many visitors, you never will hit the
performance ceiling. As soon as you need more than one server, you
have to solve the session problem by limiting the synchronization of
state or other workarounds. With a buddy system, you only have limited
failover. It doesn't work with two independent data centers, unless
you continuously want to push session state around. Really, with 1
million users, and (guessing) 10.000-20.000 concurrent visitors, you
really don't want to store all that session state. It will slow things
down.
An interesting link:
http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html
Regards,
Daan van Etten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
