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 <[EMAIL PROTECTED]> wrote: > > On Jan 7, 2008 12:04 AM, C. Bergström <[EMAIL PROTECTED]> 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
