On Feb 19, 2007, at 12:24 AM, Johan Compagner wrote:
> it is not a question about storing the entire session or not.
> The idea is that the second level cache keeps the session small.
> Because if we just rely on the session to serialize by the container
> then how many pages or page versions should we keep in memory?
> we did see by the AccessStackPageMap which defaults to 7 that they can
> grow quite large on big pages that are also changing a lot.
>
> and also saving just the page is much less then serializing the
> complete
> session
> for sure if we have that 7 page/versions in by default.
Even if the session is many times larger than a single page, it
*could* be cheaper to write the entire thing to disk or a database
when the session goes "idle" than to perform lots of small writes (I
assume it's one per request for stateful pages).
not really, because what is still takes more time then the actual writing
is the serialization., under really heavy load this sort of crawls to each
other
but under normal load the serialization (that is just constant) is much much
higher
so if we would just constantly jump the complete session then the
serialization
would just cost more and more. And saving small things shouldn't matter to
much
a disk have a cache and will save many small new files pretty much just as
one.
as for clustering, i don't think that is a big problem, sticky
> session is
> the way to go
> anyway (i don't believe in the none sticky session variant at all,
> thats
> doesn't gain you anything)
I beg to differ here. If you don't have to rely on sticky sessions
then you get rock-solid failover and can therefore add and remove
nodes at will (you're basically failing over constantly under normal
operating conditions). The other big advantage is improved resource
utilization across the farm. Your load balancers distribute on a
request-by-request basis, and that can make a significant difference
in overall throughput when compared to distributing on a session-by-
session basis.
this is just not true.
first: you get also rock solid failover if you use sticky sessions.
it doesn't mean that the sessions are not replicated at all!
most of the time you have a buddy system so one server has a backup server
and if the normal server fails the buddy system takes over.
and the utilization across the farm is also the same. If the a new session
is round robin distributed then when you have 4 servers and 100 sessions
do come in then every server does get 25 sessions. It must be really really
strange then that one server is much much busier as the other. That is just
a
mathematically calculation. For example if of those 100 sessions 15
sessions
do terminate it is very likely that those are pretty equally terminated
across all servers
The performance penalty that you get if you have true round robin request
are huge.
The session must be synced before it leaves the server to all servers.
(serialized and send over)
also frames/browser tabs or async ajax request are really horrible. What
happens if 2 request at the same
time goes to the farm? 1 request goes to A en the other to B. Then we
suddenly must have
clusterwide session locking! I want to avoid synchronize(xxx) in java as
much as possible
because that is a real concurrency killer but a
synchronizeOverCluster(session) would be really horrible.
I'd like to run some tests when the SLCSS file store gets to a point
where you're reasonably happy with the performance. It will be
difficult to compare it to Tomcat's PersistentManager, but I'll try
to come up with something meaningful.
do remember we are trying to avoid serialization and writing of the file in
the request thread itself
So the request can be fast. Only the background thread(s) should do the
serialization and writing
The only time the request thread is doing something is when it comes back in
and the page that it
wants to access is not yet serialized (saved or not doesn't matter,
serialized or not is the question here)
because it must be serialized before we can release the page again because
that request could
change the page.
johan
