You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2008/01/06 22:19:37 UTC
2nd level cache store... ehcache implementation?
on the subject of 2nd level cache stores, how feasible would it be to use
ehcache as a backing store? ehcache can store things in memory, and overflow
to disk making it a hybrid to our disk based storage.
Is it reasonable to consider a caching solution such as ehcache to provide
the backend storage?
Did we ever consider ehcache as an alternative? If so, why did we not pick
it?
Martijn
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: 2nd level cache store... ehcache implementation?
Posted by Gerolf Seitz <ge...@gmail.com>.
to quote Matej (
http://www.nabble.com/forum/ViewPost.jtp?post=11611617&framed=y)
"I built a page store using ehcache but it didn't really give any
benefit, was actually slower that what we have now."
Gerolf
On Jan 6, 2008 10:30 PM, Johan Compagner <jc...@gmail.com> wrote:
> You could make such a thing as an extentions project as a special
> session store or ipagestore. But i dont see the big gain because its
> not the reading (that doesnt happen a lot, or the writing (done in
> separate thread)) the time is spend in serialization. But the overhead
> we encountered was 20% or something like that. But the gain we have is
> way less memory usage so in the end we can handle more clients with
> 1.3
>
> On 1/6/08, Martijn Dashorst <ma...@gmail.com> wrote:
> > on the subject of 2nd level cache stores, how feasible would it be to
> use
> > ehcache as a backing store? ehcache can store things in memory, and
> overflow
> > to disk making it a hybrid to our disk based storage.
> > Is it reasonable to consider a caching solution such as ehcache to
> provide
> > the backend storage?
> >
> > Did we ever consider ehcache as an alternative? If so, why did we not
> pick
> > it?
> >
> > Martijn
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
> >
>
Re: 2nd level cache store... ehcache implementation?
Posted by Matej Knopp <ma...@gmail.com>.
On Jan 7, 2008 12:47 AM, C. Bergström <cb...@netsyncro.com> wrote:
>
> On Mon, 2008-01-07 at 00:43 +0100, Matej Knopp wrote:
> > On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> > >
> > > Matej.. I haven't looked at how difficult it would be to implement, but
> > > would someone post some ehcache 2nd level cache store code so I could
> > > run some real numbers with it?
> >
> > The implementation is no longer available, because the interfaces have
> > changed. And I really don't get the benefits of ehcache pagestore
> > implementation.
> >
>
> I think the goal in this case was so that the session/back button support could be replicated to provide some HA features or failover capability.
>
> With the current pagestore how do you scale back button support past a single node?
Also there is planned an improvement for
DiskPageStore/SecondLevelCacheSessionStore that would make HA and
backbutton possible to a certain degree. E.g. replicating page from
node A to node B (which happens on cluster) would immediately write
the page to node B pagestore, so there would be back button support.
-Matej
>
> ./C
>
>
Re: 2nd level cache store... ehcache implementation?
Posted by Matej Knopp <ma...@gmail.com>.
In order to have HA support past last visited page (which is what we
have now), you would have to use eh cache in distributed mode. I've
tried this, it's dog-slow. ehcache uses RMI for remote calls and it
really really is slow. Sorry.
Also, EHCache is a cache. It's not storage. That's a fundamental
difference. Cache is for objects can be recreated. That's not true for
serialized wicket pages.
-Matej
On Jan 7, 2008 12:47 AM, C. Bergström <cb...@netsyncro.com> wrote:
>
> On Mon, 2008-01-07 at 00:43 +0100, Matej Knopp wrote:
> > On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> > >
> > > Matej.. I haven't looked at how difficult it would be to implement, but
> > > would someone post some ehcache 2nd level cache store code so I could
> > > run some real numbers with it?
> >
> > The implementation is no longer available, because the interfaces have
> > changed. And I really don't get the benefits of ehcache pagestore
> > implementation.
> >
>
> I think the goal in this case was so that the session/back button support could be replicated to provide some HA features or failover capability.
>
> With the current pagestore how do you scale back button support past a single node?
>
> ./C
>
>
Re: 2nd level cache store... ehcache implementation?
Posted by "C. Bergström" <cb...@netsyncro.com>.
On Mon, 2008-01-07 at 00:43 +0100, Matej Knopp wrote:
> On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> >
> > Matej.. I haven't looked at how difficult it would be to implement, but
> > would someone post some ehcache 2nd level cache store code so I could
> > run some real numbers with it?
>
> The implementation is no longer available, because the interfaces have
> changed. And I really don't get the benefits of ehcache pagestore
> implementation.
>
I think the goal in this case was so that the session/back button support could be replicated to provide some HA features or failover capability.
With the current pagestore how do you scale back button support past a single node?
./C
Re: 2nd level cache store... ehcache implementation?
Posted by Matej Knopp <ma...@gmail.com>.
It's a cache. Not a storage. And it's much slower than diskpagestore.
What else needs to be said there?
You don't have to take my word for it. Just implement it, test it and see :)
-Matej
On Jan 7, 2008 12:54 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> Possible benefits: - ehcache is used by about everybody that uses hibernate
> so it is known (marketing?)
> - it is purposely built to be a cache which overflows to disk
> - it can be more finegrained tuned, stats read using jmx, etc.
> - being widely used will also (typically) mean less bugs
>
>
> You may not find this important, but others might. I think the marketing
> aspect should not be ignored. Having alternatives for when the default
> implementation is not sufficient, or has a bug, or whatever is a huge
> benefit, if only to be able to say there's an alternative implementation.
>
> Martijn
>
>
> On 1/7/08, Matej Knopp <ma...@gmail.com> wrote:
> >
> > On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> > >
> > > On Sun, 2008-01-06 at 22:30 +0100, Johan Compagner wrote:
> > > > You could make such a thing as an extentions project as a special
> > > > session store or ipagestore. But i dont see the big gain because its
> > > > not the reading (that doesnt happen a lot, or the writing (done in
> > > > separate thread)) the time is spend in serialization. But the overhead
> > > > we encountered was 20% or something like that. But the gain we have is
> > > > way less memory usage so in the end we can handle more clients with
> > > > 1.3
> > >
> > > Can we define 'way less' ? I've also been giving this some thought and
> > > what's the use pattern for the back button..
> > >
> > > Speaking of 20% performance hits.. Take a look at the difference between
> > > beta3 and 1.3 final.. There were some threading changes which certainly
> > > had an impact. (This is more a general observation based on casual
> > > testing.)
> > >
> > > Feel free to ignore these questions as I'm more 'thinking out loud' and
> > > can answer them myself..
> > >
> > > 1) How often do people click the back button in my app?
> > > 2) Do we notice any trends? Such as the max duration any user for my app
> > > has used the back button? (say 1-5 minutes)
> > > 3) How many versions back did they actually use?
> > > 4) Am I willing to trade off losing user density per node for being able
> > > to effectively cluster easily?
> > > 5) Can I just reverse proxy my app and use sticky sessions to push user
> > > foo always to a specific node?
> > > 6) For pages with a complex component hierarchy how memory usage are we
> > > *really* talking and how could I measure/estimate this?
> > >
> > >
> > > Lets use some imaginary numbers..
> > > Dell Poweredge with 4GB ram (I've seen this setup in production using
> > > Wicket)
> > >
> > > On a real app using hibernate and a multitude of things going on in the
> > > background I've seen the app roughly be able to handle 50 requests per
> > > second when testing with siege and a recorded click pattern. (We were
> > > running some *heavy* reports to explain why this number is so low) (We
> > > can compare this to 4200~ rps for a Wicket hello world and 5300~ using
> > > lighttpd serving static content.) So with this sort of use case and
> > > theoretical max users the amount of memory usage can't be *that* high in
> > > order to justify not having the convenience/features to use something
> > > like ehcache.
> > >
> > > Matej.. I haven't looked at how difficult it would be to implement, but
> > > would someone post some ehcache 2nd level cache store code so I could
> > > run some real numbers with it?
> >
> > The implementation is no longer available, because the interfaces have
> > changed. And I really don't get the benefits of ehcache pagestore
> > implementation.
> >
> > -Matej
> >
> > >
> > > Thanks
> > >
> > > ./C
> > >
> > >
> >
>
>
>
> --
>
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
Re: 2nd level cache store... ehcache implementation?
Posted by Johan Compagner <jc...@gmail.com>.
Why do you want to keep it in mem?
for a thing that is almost 90% or more write only it will never be read back
it
so caching it like that is in my eyes nonsense. Let the OS handle that thats
what an os is good at.
EHCache is mostly used for 90% reads and 10% writes or something like that.
But the page store is just the opposite.
I also don't see any benifit in using EHCache. Pages need to be flushed away
as fast as possible.
Because it only clutters memory. Just as a normal HttpSession store does.
Especially with
big repeater views.. they can eat up a lot in 1.2
johan
On 1/7/08, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Possible benefits: - ehcache is used by about everybody that uses
> hibernate
> so it is known (marketing?)
> - it is purposely built to be a cache which overflows to disk
> - it can be more finegrained tuned, stats read using jmx, etc.
> - being widely used will also (typically) mean less bugs
>
>
> You may not find this important, but others might. I think the marketing
> aspect should not be ignored. Having alternatives for when the default
> implementation is not sufficient, or has a bug, or whatever is a huge
> benefit, if only to be able to say there's an alternative implementation.
>
> Martijn
>
> On 1/7/08, Matej Knopp <ma...@gmail.com> wrote:
> >
> > On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> > >
> > > On Sun, 2008-01-06 at 22:30 +0100, Johan Compagner wrote:
> > > > You could make such a thing as an extentions project as a special
> > > > session store or ipagestore. But i dont see the big gain because its
> > > > not the reading (that doesnt happen a lot, or the writing (done in
> > > > separate thread)) the time is spend in serialization. But the
> overhead
> > > > we encountered was 20% or something like that. But the gain we have
> is
> > > > way less memory usage so in the end we can handle more clients with
> > > > 1.3
> > >
> > > Can we define 'way less' ? I've also been giving this some thought and
> > > what's the use pattern for the back button..
> > >
> > > Speaking of 20% performance hits.. Take a look at the difference
> between
> > > beta3 and 1.3 final.. There were some threading changes which
> certainly
> > > had an impact. (This is more a general observation based on casual
> > > testing.)
> > >
> > > Feel free to ignore these questions as I'm more 'thinking out loud'
> and
> > > can answer them myself..
> > >
> > > 1) How often do people click the back button in my app?
> > > 2) Do we notice any trends? Such as the max duration any user for my
> app
> > > has used the back button? (say 1-5 minutes)
> > > 3) How many versions back did they actually use?
> > > 4) Am I willing to trade off losing user density per node for being
> able
> > > to effectively cluster easily?
> > > 5) Can I just reverse proxy my app and use sticky sessions to push
> user
> > > foo always to a specific node?
> > > 6) For pages with a complex component hierarchy how memory usage are
> we
> > > *really* talking and how could I measure/estimate this?
> > >
> > >
> > > Lets use some imaginary numbers..
> > > Dell Poweredge with 4GB ram (I've seen this setup in production using
> > > Wicket)
> > >
> > > On a real app using hibernate and a multitude of things going on in
> the
> > > background I've seen the app roughly be able to handle 50 requests per
> > > second when testing with siege and a recorded click pattern. (We were
> > > running some *heavy* reports to explain why this number is so
> low) (We
> > > can compare this to 4200~ rps for a Wicket hello world and 5300~ using
> > > lighttpd serving static content.) So with this sort of use case and
> > > theoretical max users the amount of memory usage can't be *that* high
> in
> > > order to justify not having the convenience/features to use something
> > > like ehcache.
> > >
> > > Matej.. I haven't looked at how difficult it would be to implement,
> but
> > > would someone post some ehcache 2nd level cache store code so I could
> > > run some real numbers with it?
> >
> > The implementation is no longer available, because the interfaces have
> > changed. And I really don't get the benefits of ehcache pagestore
> > implementation.
> >
> > -Matej
> >
> > >
> > > Thanks
> > >
> > > ./C
> > >
> > >
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
Re: 2nd level cache store... ehcache implementation?
Posted by Martijn Dashorst <ma...@gmail.com>.
Possible benefits: - ehcache is used by about everybody that uses hibernate
so it is known (marketing?)
- it is purposely built to be a cache which overflows to disk
- it can be more finegrained tuned, stats read using jmx, etc.
- being widely used will also (typically) mean less bugs
You may not find this important, but others might. I think the marketing
aspect should not be ignored. Having alternatives for when the default
implementation is not sufficient, or has a bug, or whatever is a huge
benefit, if only to be able to say there's an alternative implementation.
Martijn
On 1/7/08, Matej Knopp <ma...@gmail.com> wrote:
>
> On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
> >
> > On Sun, 2008-01-06 at 22:30 +0100, Johan Compagner wrote:
> > > You could make such a thing as an extentions project as a special
> > > session store or ipagestore. But i dont see the big gain because its
> > > not the reading (that doesnt happen a lot, or the writing (done in
> > > separate thread)) the time is spend in serialization. But the overhead
> > > we encountered was 20% or something like that. But the gain we have is
> > > way less memory usage so in the end we can handle more clients with
> > > 1.3
> >
> > Can we define 'way less' ? I've also been giving this some thought and
> > what's the use pattern for the back button..
> >
> > Speaking of 20% performance hits.. Take a look at the difference between
> > beta3 and 1.3 final.. There were some threading changes which certainly
> > had an impact. (This is more a general observation based on casual
> > testing.)
> >
> > Feel free to ignore these questions as I'm more 'thinking out loud' and
> > can answer them myself..
> >
> > 1) How often do people click the back button in my app?
> > 2) Do we notice any trends? Such as the max duration any user for my app
> > has used the back button? (say 1-5 minutes)
> > 3) How many versions back did they actually use?
> > 4) Am I willing to trade off losing user density per node for being able
> > to effectively cluster easily?
> > 5) Can I just reverse proxy my app and use sticky sessions to push user
> > foo always to a specific node?
> > 6) For pages with a complex component hierarchy how memory usage are we
> > *really* talking and how could I measure/estimate this?
> >
> >
> > Lets use some imaginary numbers..
> > Dell Poweredge with 4GB ram (I've seen this setup in production using
> > Wicket)
> >
> > On a real app using hibernate and a multitude of things going on in the
> > background I've seen the app roughly be able to handle 50 requests per
> > second when testing with siege and a recorded click pattern. (We were
> > running some *heavy* reports to explain why this number is so low) (We
> > can compare this to 4200~ rps for a Wicket hello world and 5300~ using
> > lighttpd serving static content.) So with this sort of use case and
> > theoretical max users the amount of memory usage can't be *that* high in
> > order to justify not having the convenience/features to use something
> > like ehcache.
> >
> > Matej.. I haven't looked at how difficult it would be to implement, but
> > would someone post some ehcache 2nd level cache store code so I could
> > run some real numbers with it?
>
> The implementation is no longer available, because the interfaces have
> changed. And I really don't get the benefits of ehcache pagestore
> implementation.
>
> -Matej
>
> >
> > Thanks
> >
> > ./C
> >
> >
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
Re: 2nd level cache store... ehcache implementation?
Posted by Matej Knopp <ma...@gmail.com>.
On Jan 7, 2008 12:04 AM, C. Bergström <cb...@netsyncro.com> wrote:
>
> On Sun, 2008-01-06 at 22:30 +0100, Johan Compagner wrote:
> > You could make such a thing as an extentions project as a special
> > session store or ipagestore. But i dont see the big gain because its
> > not the reading (that doesnt happen a lot, or the writing (done in
> > separate thread)) the time is spend in serialization. But the overhead
> > we encountered was 20% or something like that. But the gain we have is
> > way less memory usage so in the end we can handle more clients with
> > 1.3
>
> Can we define 'way less' ? I've also been giving this some thought and
> what's the use pattern for the back button..
>
> Speaking of 20% performance hits.. Take a look at the difference between
> beta3 and 1.3 final.. There were some threading changes which certainly
> had an impact. (This is more a general observation based on casual
> testing.)
>
> Feel free to ignore these questions as I'm more 'thinking out loud' and
> can answer them myself..
>
> 1) How often do people click the back button in my app?
> 2) Do we notice any trends? Such as the max duration any user for my app
> has used the back button? (say 1-5 minutes)
> 3) How many versions back did they actually use?
> 4) Am I willing to trade off losing user density per node for being able
> to effectively cluster easily?
> 5) Can I just reverse proxy my app and use sticky sessions to push user
> foo always to a specific node?
> 6) For pages with a complex component hierarchy how memory usage are we
> *really* talking and how could I measure/estimate this?
>
>
> Lets use some imaginary numbers..
> Dell Poweredge with 4GB ram (I've seen this setup in production using
> Wicket)
>
> On a real app using hibernate and a multitude of things going on in the
> background I've seen the app roughly be able to handle 50 requests per
> second when testing with siege and a recorded click pattern. (We were
> running some *heavy* reports to explain why this number is so low) (We
> can compare this to 4200~ rps for a Wicket hello world and 5300~ using
> lighttpd serving static content.) So with this sort of use case and
> theoretical max users the amount of memory usage can't be *that* high in
> order to justify not having the convenience/features to use something
> like ehcache.
>
> Matej.. I haven't looked at how difficult it would be to implement, but
> would someone post some ehcache 2nd level cache store code so I could
> run some real numbers with it?
The implementation is no longer available, because the interfaces have
changed. And I really don't get the benefits of ehcache pagestore
implementation.
-Matej
>
> Thanks
>
> ./C
>
>
Re: 2nd level cache store... ehcache implementation?
Posted by "C. Bergström" <cb...@netsyncro.com>.
On Sun, 2008-01-06 at 22:30 +0100, Johan Compagner wrote:
> You could make such a thing as an extentions project as a special
> session store or ipagestore. But i dont see the big gain because its
> not the reading (that doesnt happen a lot, or the writing (done in
> separate thread)) the time is spend in serialization. But the overhead
> we encountered was 20% or something like that. But the gain we have is
> way less memory usage so in the end we can handle more clients with
> 1.3
Can we define 'way less' ? I've also been giving this some thought and
what's the use pattern for the back button..
Speaking of 20% performance hits.. Take a look at the difference between
beta3 and 1.3 final.. There were some threading changes which certainly
had an impact. (This is more a general observation based on casual
testing.)
Feel free to ignore these questions as I'm more 'thinking out loud' and
can answer them myself..
1) How often do people click the back button in my app?
2) Do we notice any trends? Such as the max duration any user for my app
has used the back button? (say 1-5 minutes)
3) How many versions back did they actually use?
4) Am I willing to trade off losing user density per node for being able
to effectively cluster easily?
5) Can I just reverse proxy my app and use sticky sessions to push user
foo always to a specific node?
6) For pages with a complex component hierarchy how memory usage are we
*really* talking and how could I measure/estimate this?
Lets use some imaginary numbers..
Dell Poweredge with 4GB ram (I've seen this setup in production using
Wicket)
On a real app using hibernate and a multitude of things going on in the
background I've seen the app roughly be able to handle 50 requests per
second when testing with siege and a recorded click pattern. (We were
running some *heavy* reports to explain why this number is so low) (We
can compare this to 4200~ rps for a Wicket hello world and 5300~ using
lighttpd serving static content.) So with this sort of use case and
theoretical max users the amount of memory usage can't be *that* high in
order to justify not having the convenience/features to use something
like ehcache.
Matej.. I haven't looked at how difficult it would be to implement, but
would someone post some ehcache 2nd level cache store code so I could
run some real numbers with it?
Thanks
./C
Re: 2nd level cache store... ehcache implementation?
Posted by Johan Compagner <jc...@gmail.com>.
You could make such a thing as an extentions project as a special
session store or ipagestore. But i dont see the big gain because its
not the reading (that doesnt happen a lot, or the writing (done in
separate thread)) the time is spend in serialization. But the overhead
we encountered was 20% or something like that. But the gain we have is
way less memory usage so in the end we can handle more clients with
1.3
On 1/6/08, Martijn Dashorst <ma...@gmail.com> wrote:
> on the subject of 2nd level cache stores, how feasible would it be to use
> ehcache as a backing store? ehcache can store things in memory, and overflow
> to disk making it a hybrid to our disk based storage.
> Is it reasonable to consider a caching solution such as ehcache to provide
> the backend storage?
>
> Did we ever consider ehcache as an alternative? If so, why did we not pick
> it?
>
> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
Re: 2nd level cache store... ehcache implementation?
Posted by Matej Knopp <ma...@gmail.com>.
I have built an ehcache implementation, but it really was slower.
The thing is, writing to disk has a very little overhead. We keep
certain amount of the file handles open so vast majority of writes is
cached by the filesystem. So instead of lot of small writes there are
way less frequent writes bigger amounts of data.
I really see no benefit at all in using ehcache.
-Matej
On Jan 6, 2008 10:19 PM, Martijn Dashorst <ma...@gmail.com> wrote:
> on the subject of 2nd level cache stores, how feasible would it be to use
> ehcache as a backing store? ehcache can store things in memory, and overflow
> to disk making it a hybrid to our disk based storage.
> Is it reasonable to consider a caching solution such as ehcache to provide
> the backend storage?
>
> Did we ever consider ehcache as an alternative? If so, why did we not pick
> it?
>
> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>