Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

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

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> not yet, i did try to set it up once but i missed the load balancer
> that is pretty crucial  to have it up and running easily. (like resin
> balancer)

Depends on what you need to test though. Though have a pretty nice gui
where you can exactly view the data that is kept on the terracotta
server. So you don't really need to actually distribute requests at
all to test it.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

not yet, i did try to set it up once but i missed the load balancer
that is pretty crucial  to have it up and running easily. (like resin
balancer)

johan


On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> > really?
> > How are they doing the url compressor stuff then?
> > Or i guess they have special support for soft/weak References ..
> > because you can't serialize a weak or soft reference.
> >
> > If you make a test, use the WebCompressing strategy and look what
> happens
> > with the URLCompressor class.
>
> Did you try it? Asked them whether/ how this would work?
>
> Eelco
>

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> really?
> How are they doing the url compressor stuff then?
> Or i guess they have special support for soft/weak References ..
> because you can't serialize a weak or soft reference.
>
> If you make a test, use the WebCompressing strategy and look what happens
> with the URLCompressor class.

Did you try it? Asked them whether/ how this would work?

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Igor Vaynberg <ig...@gmail.com>]

those are the kinds of things that are going to break and we have to "fix"
for terracotta somehow in their config.

-igor


On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
>
> really?
> How are they doing the url compressor stuff then?
> Or i guess they have special support for soft/weak References ..
> because you can't serialize a weak or soft reference.
>
> If you make a test, use the WebCompressing strategy and look what happens
> with the URLCompressor class.
>
> johan
>
>
> On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > right, thats what i meant
> >
> > -igor
> >
> >
> > On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > And they don't have to. At least not according to what they are doing
> > with
> > > it.
> > >
> > > Eelco
> > >
> > > On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > they dont
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> > > > >
> > > > > i am very interested how the handle the special serialization
> cases.
> > > > > like readObject and writeObject methods or writeReplace..
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > > On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > > Looking forward to it! I just started checking out Terracotta
> > > today...
> > > > > >
> > > > > > One of the great things about Terracotta that I wasn't aware of
> > > > > > yesterday, as that Terracotta can fail over when you run out of
> > > memory
> > > > > > on a box. And that's kind of the same thing (not quite, but in
> the
> > > > > > same line of thought) we are trying to achieve with our new
> > session
> > > > > > store implementation. The SLCSS implementation will always have
> > the
> > > > > > advantage that there is unlimited back button support. For what
> it
> > > is
> > > > > > worth. But I think that even running Terracotta on the same
> > machine
> > > -
> > > > > > when the Terracotta server runs out of RAM it'll start using the
> > > disk
> > > > > > - to prevent running out of memory is a viable option. And
> > > Terracotta
> > > > > > is by default a lot more efficient in how it does that than any
> > > normal
> > > > > > serialization based solution out there.
> > > > > >
> > > > > > Anyway, like I said, I think we should definitively look in this
> > > > > > direction as well. We already were in fact, but it deserves more
> > > > > > priority.
> > > > > >
> > > > > > Ryan, we'll be very interested to hear your experiences with it.
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

really?
How are they doing the url compressor stuff then?
Or i guess they have special support for soft/weak References ..
because you can't serialize a weak or soft reference.

If you make a test, use the WebCompressing strategy and look what happens
with the URLCompressor class.

johan


On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> right, thats what i meant
>
> -igor
>
>
> On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > And they don't have to. At least not according to what they are doing
> with
> > it.
> >
> > Eelco
> >
> > On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > they dont
> > >
> > > -igor
> > >
> > >
> > > On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > > i am very interested how the handle the special serialization cases.
> > > > like readObject and writeObject methods or writeReplace..
> > > >
> > > > johan
> > > >
> > > >
> > > > On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > > Looking forward to it! I just started checking out Terracotta
> > today...
> > > > >
> > > > > One of the great things about Terracotta that I wasn't aware of
> > > > > yesterday, as that Terracotta can fail over when you run out of
> > memory
> > > > > on a box. And that's kind of the same thing (not quite, but in the
> > > > > same line of thought) we are trying to achieve with our new
> session
> > > > > store implementation. The SLCSS implementation will always have
> the
> > > > > advantage that there is unlimited back button support. For what it
> > is
> > > > > worth. But I think that even running Terracotta on the same
> machine
> > -
> > > > > when the Terracotta server runs out of RAM it'll start using the
> > disk
> > > > > - to prevent running out of memory is a viable option. And
> > Terracotta
> > > > > is by default a lot more efficient in how it does that than any
> > normal
> > > > > serialization based solution out there.
> > > > >
> > > > > Anyway, like I said, I think we should definitively look in this
> > > > > direction as well. We already were in fact, but it deserves more
> > > > > priority.
> > > > >
> > > > > Ryan, we'll be very interested to hear your experiences with it.
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>

Re: Questions about SecondLevelCacheSessionStore

[Igor Vaynberg <ig...@gmail.com>]

right, thats what i meant

-igor


On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> And they don't have to. At least not according to what they are doing with
> it.
>
> Eelco
>
> On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > they dont
> >
> > -igor
> >
> >
> > On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > i am very interested how the handle the special serialization cases.
> > > like readObject and writeObject methods or writeReplace..
> > >
> > > johan
> > >
> > >
> > > On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > Looking forward to it! I just started checking out Terracotta
> today...
> > > >
> > > > One of the great things about Terracotta that I wasn't aware of
> > > > yesterday, as that Terracotta can fail over when you run out of
> memory
> > > > on a box. And that's kind of the same thing (not quite, but in the
> > > > same line of thought) we are trying to achieve with our new session
> > > > store implementation. The SLCSS implementation will always have the
> > > > advantage that there is unlimited back button support. For what it
> is
> > > > worth. But I think that even running Terracotta on the same machine
> -
> > > > when the Terracotta server runs out of RAM it'll start using the
> disk
> > > > - to prevent running out of memory is a viable option. And
> Terracotta
> > > > is by default a lot more efficient in how it does that than any
> normal
> > > > serialization based solution out there.
> > > >
> > > > Anyway, like I said, I think we should definitively look in this
> > > > direction as well. We already were in fact, but it deserves more
> > > > priority.
> > > >
> > > > Ryan, we'll be very interested to hear your experiences with it.
> > > >
> > > > Eelco
> > > >
> > >
> >
>

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

And they don't have to. At least not according to what they are doing with it.

Eelco

On 2/21/07, Igor Vaynberg <ig...@gmail.com> wrote:
> they dont
>
> -igor
>
>
> On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > i am very interested how the handle the special serialization cases.
> > like readObject and writeObject methods or writeReplace..
> >
> > johan
> >
> >
> > On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > Looking forward to it! I just started checking out Terracotta today...
> > >
> > > One of the great things about Terracotta that I wasn't aware of
> > > yesterday, as that Terracotta can fail over when you run out of memory
> > > on a box. And that's kind of the same thing (not quite, but in the
> > > same line of thought) we are trying to achieve with our new session
> > > store implementation. The SLCSS implementation will always have the
> > > advantage that there is unlimited back button support. For what it is
> > > worth. But I think that even running Terracotta on the same machine -
> > > when the Terracotta server runs out of RAM it'll start using the disk
> > > - to prevent running out of memory is a viable option. And Terracotta
> > > is by default a lot more efficient in how it does that than any normal
> > > serialization based solution out there.
> > >
> > > Anyway, like I said, I think we should definitively look in this
> > > direction as well. We already were in fact, but it deserves more
> > > priority.
> > >
> > > Ryan, we'll be very interested to hear your experiences with it.
> > >
> > > Eelco
> > >
> >
>

Re: Questions about SecondLevelCacheSessionStore

[Igor Vaynberg <ig...@gmail.com>]

they dont

-igor


On 2/21/07, Johan Compagner <jc...@gmail.com> wrote:
>
> i am very interested how the handle the special serialization cases.
> like readObject and writeObject methods or writeReplace..
>
> johan
>
>
> On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > Looking forward to it! I just started checking out Terracotta today...
> >
> > One of the great things about Terracotta that I wasn't aware of
> > yesterday, as that Terracotta can fail over when you run out of memory
> > on a box. And that's kind of the same thing (not quite, but in the
> > same line of thought) we are trying to achieve with our new session
> > store implementation. The SLCSS implementation will always have the
> > advantage that there is unlimited back button support. For what it is
> > worth. But I think that even running Terracotta on the same machine -
> > when the Terracotta server runs out of RAM it'll start using the disk
> > - to prevent running out of memory is a viable option. And Terracotta
> > is by default a lot more efficient in how it does that than any normal
> > serialization based solution out there.
> >
> > Anyway, like I said, I think we should definitively look in this
> > direction as well. We already were in fact, but it deserves more
> > priority.
> >
> > Ryan, we'll be very interested to hear your experiences with it.
> >
> > Eelco
> >
>

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

i am very interested how the handle the special serialization cases.
like readObject and writeObject methods or writeReplace..

johan


On 2/21/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Looking forward to it! I just started checking out Terracotta today...
>
> One of the great things about Terracotta that I wasn't aware of
> yesterday, as that Terracotta can fail over when you run out of memory
> on a box. And that's kind of the same thing (not quite, but in the
> same line of thought) we are trying to achieve with our new session
> store implementation. The SLCSS implementation will always have the
> advantage that there is unlimited back button support. For what it is
> worth. But I think that even running Terracotta on the same machine -
> when the Terracotta server runs out of RAM it'll start using the disk
> - to prevent running out of memory is a viable option. And Terracotta
> is by default a lot more efficient in how it does that than any normal
> serialization based solution out there.
>
> Anyway, like I said, I think we should definitively look in this
> direction as well. We already were in fact, but it deserves more
> priority.
>
> Ryan, we'll be very interested to hear your experiences with it.
>
> Eelco
>

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> Looking forward to it! I just started checking out Terracotta today...

One of the great things about Terracotta that I wasn't aware of
yesterday, as that Terracotta can fail over when you run out of memory
on a box. And that's kind of the same thing (not quite, but in the
same line of thought) we are trying to achieve with our new session
store implementation. The SLCSS implementation will always have the
advantage that there is unlimited back button support. For what it is
worth. But I think that even running Terracotta on the same machine -
when the Terracotta server runs out of RAM it'll start using the disk
- to prevent running out of memory is a viable option. And Terracotta
is by default a lot more efficient in how it does that than any normal
serialization based solution out there.

Anyway, like I said, I think we should definitively look in this
direction as well. We already were in fact, but it deserves more
priority.

Ryan, we'll be very interested to hear your experiences with it.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

On Feb 21, 2007, at 1:54 AM, Eelco Hillenius wrote:

> FYI, we (Jonathan and I) just came from a presentation on Terracotta.
> I think we have a pretty good idea now how we can support Terracotta
> best (just a couple of lines of code really) and we're convinced that
> this Wicket/Terracotta combi will probably be the way to go for most
> medium to large sized production environments with Wicket. At least it
> is the area where I would like to spend some more energy on when it
> comes to optimizing Wicket for scalability purposes.
>
> I'll give a heads up on this in a new thread when we make progress  
> on it.
>
> Eelco

Looking forward to it! I just started checking out Terracotta today...

-Ryan

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

FYI, we (Jonathan and I) just came from a presentation on Terracotta.
I think we have a pretty good idea now how we can support Terracotta
best (just a couple of lines of code really) and we're convinced that
this Wicket/Terracotta combi will probably be the way to go for most
medium to large sized production environments with Wicket. At least it
is the area where I would like to spend some more energy on when it
comes to optimizing Wicket for scalability purposes.

I'll give a heads up on this in a new thread when we make progress on it.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> 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.

That's always very welcome. I'm about to start a discussion on it
myself actually; there's been quite some talk about it on IRC, but it
is time now for a larger audience and better history (mailing list).

Keep in mind that the SecondLevelCacheSessionStore (SLCSS) is still
experimental and that not all of Wicket's committers agree just yet
that this is the best default nor that it's current implementation is
the best. But we have some working code, which is great for
discussion.

Also keep in mind that we want to support both mechanisms (the 'old'
totally RAM based and this new one) and any mechanisms people use for
themselves.

> 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)?

The idea of having a custom implementation is that we can (potentially
at least) optimize it for just Wicket, and have a mechanism available
that should work regardless of the app server you are using (and the
bugs that might be in there)

> 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.

More efficient when it comes to disk writes, but not when it comes to
using RAM. We can clean up RAM quicker and thus need less RAM per
session in the short run. And the short run is better for handling
peaks.

> 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?

Yeah. This is something that we are still discussing. For starters, it
depends on whether you work with session affinity (aka sticky
sessions). If that is the case, this approach works fine. However, if
you don't and/ or want a backup without having to use a shared network
disk, I believe the file based approach isn't great.

> 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.

Sorry for being a smart ass, but the big mistake people always make in
matters like these - Wicket developers included - is make assumptions
without actually calculating and testing them. And there also isn't a
'bad' approach by default here, as what works well depends entirely on
what the traffic looks like.

> 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).

Maybe. Keep in mind we're writing in a non-blocking low priority
background ground thread (or at least, that is the idea) and we'll
only be reading from second level storage if the requested resource
(page) isn't available in the first level cache. And as we always hold
at least the first the current page in memory, and that is the page
that is used to resolve requests from forms and non-bookmarkable link
components etc, in practice, the second level storage is only accessed
for back button requests, for which you may argue that they'll be far
less common than normal requests (although even here, if you are
serious about your stuff you might want to collect statistics about
back button use and configure accordingly when that is possible).

> 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?

If you depend on a cluster being managed by your app server, the old
approach might be the best for you anyway. But if you are e.g. using
Terracotta - which we plan to use for the day time job I'm working on,
and which seems like an excellent match - it doesn't matter where the
data lives that needs to be clustered. We (and our users) have also
quite a few options left when it comes to triggering that clustering.
For app servers this is done by putting attributes in the HttpSession
object. When exactly you do that is part of the ISessionStore
implementation, and can thus be tweaked and optimized to your liking.
In fact, this is an area we should look at for this new second level
cache thing as well (btw, it's just a working name and I hate the name
for it's verbosity).

> 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.

No, not at all. Please discuss. I hope I cleared things up a bit - and
other devs please chip in. It's open source, so the more people think
with us, the better we can make it.

Cheers,

Eelco

p.s. I'm sending a proposal for discussing the specs of this thing
hopefully later this evening.

Re: Questions about SecondLevelCacheSessionStore

[Igor Vaynberg <ig...@gmail.com>]

On 2/19/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> 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.


deltas/changes, whatever you call them, often have references to the page
through anonymous classes, etc. so it ends up being the same


> 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.


the con is that you lose data-locality in your caches. if you are using
something like hibernate or doing caching on your own sticky sessions
dramatically improve hit/miss ratio


-igor

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

>
>
> doing this asynchronously from the request does kill any fail-over
> strategy
> though :(



only when that page was just not saved before a crash and then
only for a back button when the failover did happen and the user uses the
back button.
just after that.
personally, i can live with that.

But we could make a setting that everything happens in the request thread?

but we have some saying here in holland:

how high are we going to build the banks to keep the water out.
(or are you calculating that it sometimes under rare circumstances it can go
wrong but that will keep the cost down)

johan

Re: Questions about SecondLevelCacheSessionStore

[Igor Vaynberg <ig...@gmail.com>]

On 2/20/07, Johan Compagner <jc...@gmail.com> wrote:
>
> 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.


doing this asynchronously from the request does kill any fail-over strategy
though :(

-igor




johan
>

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> > Eelco
> Understood, and this issue certainly wouldn't keep me from using or
> recommending Wicket. Nor would it be out of line with other Java web
> products that either explicitly or practically require sticky
> sessions. I'm caught up in the discussion and didn't mean to blow it
> out of proportion.

Sure. I don't think you blew it out of proportions. Just stating that
while it would be possible to build in client state saving support,
due to the lack of resources it is unlikely we'll have that very soon.
But if someone out of the team would want to start on it, we would try
to give some support to it.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

On Feb 21, 2007, at 1:43 AM, Eelco Hillenius wrote:
> True up to some point. We're all still volunteers meaning that we're
> mostly working on this on our free time. Even though at least half of
> the team members use Wicket for our daily jobs, most of the work is
> done in the evenings and weekends. That is why we don't have client
> state saving (like e.g. JSF does). It would be possible to implement
> and while it would probably mean 'selling' Wicket easier in some
> occasions, we just don't think it is worth our time at this stage, as
> none of the core developers thinks this would be a better solution
> than keeping server state.
>
> There are advantages to not having to keep session affinity. But there
> are advantages to having a statefull programming model as well. It's a
> bunch of tradeoffs in the end, and we have to pick our battles.
>
> Eelco
Understood, and this issue certainly wouldn't keep me from using or  
recommending Wicket. Nor would it be out of line with other Java web  
products that either explicitly or practically require sticky  
sessions. I'm caught up in the discussion and didn't mean to blow it  
out of proportion.

-Ryan

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> 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.

True up to some point. We're all still volunteers meaning that we're
mostly working on this on our free time. Even though at least half of
the team members use Wicket for our daily jobs, most of the work is
done in the evenings and weekends. That is why we don't have client
state saving (like e.g. JSF does). It would be possible to implement
and while it would probably mean 'selling' Wicket easier in some
occasions, we just don't think it is worth our time at this stage, as
none of the core developers thinks this would be a better solution
than keeping server state.

There are advantages to not having to keep session affinity. But there
are advantages to having a statefull programming model as well. It's a
bunch of tradeoffs in the end, and we have to pick our battles.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> is almost everytime 0ms. Serializing is much higer lowest 32ms but can go
> through 200ms)

That much? I rarely have serializations that take more than 20ms
except for the first time classes are hit.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Eelco Hillenius <ee...@gmail.com>]

> no this is not more common.. because the total of 50 users was round robin
> assigned to different servers (lets say 2). Then it is very unlikely that
> just that 25 users of that one server are very busy and the other 25 of that
> other server not
> that is just math..

Such statistics are likely for intranet-like applications, and I'm
sure they may be true on the *very* large scale of public facing
sites. However, I don't think there's a golden rule in this case
either. I can totally imagine a very uneven distribution on a public
facing sites with a very mixed picture of light- and heavy users.
Users that'll come on that site and leave after a couple of clicks,
and users that spend an hour working on it.

Eelco

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

> > 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.



no this is not more common.. because the total of 50 users was round robin
assigned to different servers (lets say 2). Then it is very unlikely that
just that 25 users of that one server are very busy and the other 25 of that
other server not
that is just math..

for example 4 servers and we get 1000 session , every server gets 250
sessions to handle

then if of those 1000 session 150 sessions are very busy. That it is very
likely that those
are evenly divided over the 4 servers (just calculate the probability!)
How bigger the numbers of session and how more equally divided it will be.
If after a while of those 1000 session 300 will be terminated again it is
very likely that
that is evenly divided over the 4 servers. So after 1000 new sessions round
robin created
over 4 servers then randomly 400 terminate then i think that in a small
bandwidth
all the servers would be around 150 active sessions.

How many times will a well balanced coin fall on the head and how many times
on the tail?


> 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.


yes but that has the overhead again of serialization every time. And syncing
over servers (done through database)
And you have a single point of failure.


> 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.


no, wicket can handle many request at the same time
Resource request for example where always already possible.
In a none sticky in wont.
And now we relaxed the syncing on the session.
We only lock on the pagemap of a page. So a popup or another tab can do the
same thing.
So if you access the same page or another page in the same pagemap twice we
will block
the rest can go concurrently.

> 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 ;)


keep shooting :)

johan

Re: Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

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

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

> 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.


i was also talking about the OS cache. As i said if i look at  a very simple
load
like i am clicking through the application my self. Then saving the page
(the count in java)
is almost everytime 0ms. Serializing is much higer lowest 32ms but can go
through 200ms)

Of course if the load gets much higher, and then i mean like our stress
test. Then the serialization
time and the saving time are getting closer to each other, because the
disk/os cache is completely filled up.

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....


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.\


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)

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.

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.
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%)


> 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..


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

Re: Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

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

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

>
> 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

Re: Questions about SecondLevelCacheSessionStore

[Ryan Holmes <ry...@hyperstep.com>]

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 <ry...@hyperstep.com> 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
>>
>>

Re: Questions about SecondLevelCacheSessionStore

[Johan Compagner <jc...@gmail.com>]

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.

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)
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


On 2/19/07, Ryan Holmes <ry...@hyperstep.com> 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
>
>