On Feb 21, 2007, at 1:47 AM, Johan Compagner wrote:
About saving bigger files.. Any idea's? combine pages when i see
that there
are multiply for one session?
But how can i then read them back in easily, i need to build then
some kind
of filesystem in a filesystem == db....
Yes, since the serialization/write happens asynch I had wondered if
there would be an opportunity to coalesce writes yourself. No idea if
it's actually worth doing, especially because of that last point.
look for example the resins build in sticky session clustering.
You do know and care that a session is replicated. But it is only
replicated
to
one other server (its buddy)
Of course if the main server and its buddy are both going done at
the same
time
then you would loose sessions. but this is mostly true for all kind
if RAID
things
(if in a typical RAID config 2 hd's at the same time are killed you
could
have a problem)
Totally agree that if your cluster is "tolerant enough", you don't
need it to be more tolerant.
If every server has to read in the session from the database (and do a
select for update)
for every request. That means deserializing and serializing for every
request the complete session
(complete can maybe be optimized...) That would mean a really
performance
penalty.
Per-request performance is definitely not a strong suit of non-sticky
sessions.
While sessions will distribute evenly, what really matters with
regard to resource utilization is the distribution of individual
requests and their operations. The finer grained model of
distributing per request has an advantage in that the system as a
whole reacts much faster to changing load (it's essentially
instantaneous).
its just a matter of numbers. If you use sticky sessions with round
robin
new session creation
it is very common that the load would be exactly the same over all the
servers.
It's more common that it wouldn't. One group of 25 users probably has
a very different level of activity than a different group of 25.
one other pro for sticky sessions with buddy system is that you
also gain
memory.
If for example you replicate to all servers then all the servers
will have
all the sessions in memory.
with a buddy system this is with 2 servers ofcourse the same but
then in
drops (4 servers it is 50%)
The memory advantage goes to non-sticky sessions because there is no
session replication -- only a separate, central store. Each server
only has the sessions in memory for the requests it is serving at a
given moment. After the request, the session is eligible for GC.
That's not really an issue in a "typical" non-sticky session
configuration: session data is read at the beginning of a request
and, if the session is updated, written at the end of the request to
a central database. The idea is to push concurrency issues to the
database instead of handling them in code. The DB can handle
simultaneous selects and/or updates from different servers easily
and, if you want serialized requests, you can use SELECT FOR UPDATE
or the equivalent lock when you read the session row.
and this is want i meant with synching over the complete cluster
The gain you think you have is completely killed. Because all other
servers
that
access the same session are waiting for the other on the complete.
And cpu penalty for the deserialing and serializing of the session
from and
to the database again..
A server that's waiting due to session locking can handle requests
for any other session, so I don't think it makes a net difference. If
it wasn't for Wicket requiring session locking (?), multiple servers
could handle requests for the same session simultaneously.
It's not a terribly elegant solution and it has a built-in
bottleneck, plus a single point of failure that can only be partially
mitigated with database replication. However, it's extremely simple
and can perform better than you might think.
i think resins buddy system will out run this system by far.
And you don't have a single point of failure.
To be clear -- I'm not trying to convince anyone that non-sticky
sessions are the holy grail of scalability. The advantages of sticky
sessions (Igor brought up the cache data locality issue, and there
are plenty of others) can easily outweigh the advantages of non-
sticky sessions. I just think it's a viable option in certain
situations. The more important point is that, imo, a web framework
shouldn't dictate scalability choices if possible.
I think in all the web frameworks that are really session based.
none sticky sessions don't have any advantages only drawbacks.
At least i haven't heard any single advantages yet in the current
thread.
johan
Well you have to give me points for trying ;)
-Ryan
-Ryan
