Hi, the benchmark was done against a very simple initial FilePageStore that was rather primitive and didn't attempt to optimize things at all. It was practically a proof of concept thing only.
Current DiskPageStore uses one file per pagemap and it optimizes the stuff pretty well. It caches serialized page instances, so that when you replicate sessions (because of clustering - if you expect very high load) the page is serialized only once (which reduces the overhead to secondlevelcachesessionstore almost down to zero in clustered environment). -Matej On 9/9/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > Hi Eelco, > > Thanks for the thorough response (as usual). We're almost done > converting from Tap 4 to Wicket 1.2 and we'll look into migrating to > 1.3 pretty soon. I was planning on reverting to the HttpSessionStore > immediately because I assumed the new disk-based store(s) traded > performance for memory efficiency (and we have the luxury of not > really caring about RAM usage due to a limited number of users in a > LAN-only environment). > > An old benchmark that Jonathan posted (http://www.jroller.com/ > JonathanLocke/entry/how_fast_is_wicket) suggested the > HttpSessionStore was noticeably faster, but I know there have been a > lot of performance improvements since then. > > I've been pretty cynical about the whole idea of a disk-based store, > actually. It always seemed like "jumping a fence" into a servlet > container/app server's area of responsibility (had a slightly nasty > argument with Johan about that). While it always sounded like a cool > and very powerful/useful *option* to build into the framework, I > never thought it would be a clear winner over HttpSessionStore. My > main fear was that it would lead to a kind of split between some > people using one store and some the other, and that it might cascade > further into the framework (e.g. design x is a better fit with SLCSS > but design y is better for HttpSessionStore) ultimately becoming a > big drag for you guys. > > So that's a long way of saying: damn, I'm impressed. Not only is > 1-2ms negligible, it sounds like the SLCSS is a conceptually simpler > approach. Oh, and sorry to Johan for being a skeptic. ;) > > -Ryan > > On Sep 8, 2007, at 2:27 PM, Eelco Hillenius wrote: > > > On 9/8/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > >> Is it not recommended because the new disk-based session store is > >> just a better all-around solution or because using the > >> httpsessionstore is dangerous or broken in some way in 1.3? > > > > It is a better all-round solution: it is more efficient memory wise, > > and the cost of serializing and saving is neglect-able in our > > experience (like 1 or 2 miliseconds per request even without Matej's > > recent optimizations). HttpSessionStore (in 1.3, but also in 1.2) > > suffers from some limitations that the SLCSS doesn't have. > > Particularly, back button history is limited, and while we don't > > experience many real problems with it, we feel that recording change > > objects isn't as robust as just serializing the page exactly as it is. > > It sounds way more efficient to do just the change objects, but > > compared to just serializing the page, it hardly seems to be in > > practice. > > > > Eelco > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
