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