I know you guys have already thought about/discussed this, but can't
you reduce the size of the page map by storing deltas? I thought I
saw a thread about it in the dev list archives... What I'm getting at
is that if you could significantly reduce the size of the page map,
there might not be a compelling reason to store it outside of the
session.
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).
Eelco already pointed out that I'm making performance assumptions
here (and that's totally valid), but it's pretty well known that lots
of small disk writes are far less efficient than fewer large writes.
It's easy to confirm this with IOMeter and an idle server.
the problem is that we are trying to find a balance between session
usage
and
speed. We are still tweaking the Serialization and FileStore
implementation
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.
As a practical matter, I'm not sure if it's at all important for a
Java web framework to support non-sticky session clustering since
Java environments seem to always rely on sticky sessions anyway. I
just think the non-sticky approach is too often dismissed based on
false assumptions (databases are slow, etc.) and it's certainly not a
good thing if SLCSS makes it more difficult to achieve that setup.
And then only in the situation where one server goes down and you
have a
failover
AND the next request of a client is the backbutton. Then they will
get a
page expired
They didn't loose the session info, or the current pages of all the
current
pagemaps only
the old pages if you don't share the directory over all the
servers. But i
don't know if that really gains
you anything..
You could drop in a DB save implementation ofcourse if you really
need it.
johan
Totally agree with that. Trading guaranteed retention of old page
state for increased load handling and scalability is a clear win.
I really appreciate your and Eelco's explanations. I'm still
skeptical, but I'm far less afraid of what you're doing now ;)
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.
-Ryan
On 2/19/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
Hi Wicket devs,
Sorry for jumping in on this list since I'm barely a Wicket user
(much less a developer), but I wanted to share some thoughts/
questions regarding your work on the SecondLevelCacheSessionStore.
1) If the main purpose is to move sessions out of RAM and onto disk
or a database, aren't you largely duplicating functionality already
(and probably more appropriately) provided at the container level
(e.g. Tomcat's PersistentManager)?
I realize that SecondLevelCacheSessionStore moves only part of a
session out of memory rather than the whole thing and so, in effect,
keeps the literal session size small. But why is it necessarily
better to swap a part of every session in and out of RAM vs swapping
entire idle sessions out of RAM and back in only when needed (this is
PersistentManager's strategy)? It seems like the PersistentManager
approach would be more efficient (less disk writes) and should
provide similar RAM savings in the long run.
2) Doesn't the SecondLevelCacheSessionStore create another data
repository that must be shared or distributed across clustered
application servers? I mean, in addition to normal session clustering
wouldn't one also have to cluster whatever gets persisted by
SecondLevelCacheSessionStore since it stores data that is essentially
an extension of the session?
3) I'm afraid that a file based session store (the default
implementation, I believe) will actually perform so badly that it
won't be useful in the type of high load environment
SecondLevelCacheSessionStore is intended to address. In my experience
with a fairly high traffic PHP site, file-based session storage is
extremely slow and you have to switch to a database-backed solution
to handle any kind of serious load (assuming that you can't hold the
sessions in RAM, which is basically not an option anyway with PHP).
I know a database implementation of SecondLevelCacheSessionStore has
been discussed, but I guess what I'm trying to point out is that the
default implementation may actually perform and scale worse than no
SecondLevelCacheSessionStore at all would. Furthermore, if a
database-
backed solution works well, why not just let the container store
entire sessions in a database and avoid adding a second layer of
session storage that must be managed in a cluster?
I apologize if these questions/suggestions are ignorant or come
across as rude. I certainly don't mean to disparage anyone's efforts
in making Wicket more scalable and I don't pretend to be a
scalability guru (although I do have a decent amount of experience in
this area that I'll be glad to talk about if that's useful). I was
just reading through some of your past discussions about
SecondLevelCacheSessionStore and I couldn't help but see a few red
flags.
Thanks,
-Ryan
