<Lurker speaking>
I'd strongly emphasize that the distributed session server scenario has
a BIG performance issue.
We're currently hooking close to 1 megabyte of information to each
session... can you imagine moving that beast during every request?
>I have written a session server implementation as you describe. There are
>significant advantages to such an implementation (as well as disadvantages).
>
>I thought I should clarify one misconception that you had.
>
>From: Matthew Dornquast <matthew@cata.com>
> > Obviously there is a cost when moving session storage "out of process"
>from
> > the tomcat vm perspective. But I think if done correctly, it will come
> > close to mirroring the performance impact of sticky sessions, thus it'd be
>a
> > wash.
>
>I don't agree with your assumption. One area that was very difficult to
>improve upon was performance. Even with dedicated, always open sockets,
>serialization of state information across processes requires new overhead.
>This overhead is much greater than the time spent performing sticky session
>logic.
>
>In all fairness, if distributed sessions could be done as quickly as sticky
>sessions, everyone would be doing it. Sticky sessions do not provide
>fail-over and distributed sessions do.
>
>jim
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
|