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]
