On Feb 20, 2007, at 1:27 AM, Johan Compagner wrote:
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.
Ahhh, I wasn't thinking about the serialization cost -- makes sense.
Whether or not it's actually slower than the write should depend on
CPU vs disk throughput (you could have a fast, modern CPU with a
single SATA drive that's already heavily loaded, for example). But in
any case, serialization cost == CPU load and that's obviously a big
factor.
Regarding a disk cache, I don't believe write acceleration is enabled
on most drives due to the inherent danger. Battery-backed write
caches in combination with a RAID controller aren't too uncommon, and
those will indeed coalesce small write operations (as will the OS
cache, I believe). Nonetheless, when I benchmarked the write speed of
one of our new servers a few weeks ago (no battery backed write
cache, but RAID 5 w/15k drives), I got nearly twice the throughput
with 1MB writes as I did with 256K writes. I don't know if that
slowing trend continues below 256K -- perhaps write coalescing would
start to kick in at that point.
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
By "rock solid" I meant more robust than a typical sticky session
environment. With a non-sticky session configuration, you don't care
which other servers might or might not have the replicated session --
all servers have access to all sessions so any of them (including
multiple nodes) can be pulled or can fail with no user interruptions.
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).
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.
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.
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.
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'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
Thanks, I didn't quite understand that before. No question that it's
a compelling design.
-Ryan
