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