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
