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 <[EMAIL PROTECTED]> 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 <[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 >
