tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grotzke <martin.grot...@googlemail.com>
Subject Re: Replicate session-object after values in object has been changed
Date Tue, 15 Feb 2011 20:46:36 GMT
On Tue, Feb 15, 2011 at 6:01 PM, Christopher Schultz
<chris@christopherschultz.net> wrote:
> On the other hand, it's very difficult for a container to determine what
> the definition of "changed" is. For instance, an object may return a
> different value for a method call depending on the current date and
> time, yet the internal state of the object hasn't actually changed.
If behaviour does not depend on internal state then the session does
not need to be replicated, as the behaviour will be the same on
different jvms with the same date/time.

> If Tomcat simply called all the method that return values, remembered them
> all, then did a comparison at the end of every request, you'd end up
> with a whole bunch of needless replication messages flying around your
> cluster. Also, remembering all those return values (and, potentially all
> the return values of sub-objects) would roughly double the size of every
> session.
I agree, not a good idea.

>
> Another technique might be to serialize an object and check against
> /that/ after every request. This also doubles the size of every session.
>
> I suppose md5(serialize(object)) could work without doubling the size of
> the objects.
This is how it's implemented for memcached-session-manager (msm): when
loading the session from memcached (either due to a tomcat failover or
when loading a non-sticky session) the hash of the byte-array is
stored. At the end of the request the session is serialized again and
the new hash is compared with the previous one. Serialization is
pluggable, default is java/jvm serialization, alternatives are e.g.
kryo, which shares the same serialization semantics like java
serialization (ignoring transient fields etc.).

For msm by default a session would get replicated if at least one
attribute was accessed (via getAttribute), so I see this change
detection (or detection that state has not changed) as some kind of
optimization to reduce I/O and network traffic.

It would be really easy to disable this automatic change detection via
configuration btw.


>
> All of these techniques will kill performance. :(
Well, what does this mean? IMHO such statements are not really useful.

I can share some facts + numbers (out of my head):
- for one of the largest german ecommerce sites we use msm for session
replication/failover
- wicket is used as web framework, wicket stores entire pagemap
(pages/component trees) in the session (for stateful pages)
- kryo is used as serialization mechanism (see
http://code.google.com/p/kryo/ and
https://github.com/eishay/jvm-serializers/wiki).
- average (serialized) session size is between 10kB and 100kB
- session serialization/replication is done asynchronously (not in the
request thread)
- overhead for msm in the request thread is ~1msec
- average session serialization time is s.th. between 1msec and 10msec
- ~20 requests per second are served by each tomcat instance

In conclusion there's not a real impact on user experience. Most of
the cpu time is used by the application, the overhead for
serialization/replication is very low.

>
> Containers probably choose not to implement anything like the above
> because the semantics of a web application's objects are simply opaque
> to the container and it doesn't make any sense to even try. It's simple
> enough to trigger a replication event by doing:
>
> session.setAttribute(key, session.getAttribute(key));

I agree, this is a very simple way to trigger replication.
Although, it has an impact on your application, as either you'll
always trigger replication, or in several places in your software you
need to know if you change session state and you have to decide if you
need to set the appropriate session attribute. Even more, you need to
know which session attribute you need to set again.

Some modern web frameworks try to provide a higher level of
abstraction so that you don't get in touch with servlet stuff. If you
need to trigger session replication via setAttribute in your
application you need to know about internals of the web framework,
which also might change. That was also my motivation to provide a
transparent session change detection.

> I am very interested in how the memcache folks accomplish this. Martin:
> is this done via careful configuration of what "changed" means or is
> everything automatic?
I hope I could clarify how it's done for msm.

Cheers,
Martin



>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1asX4ACgkQ9CaO5/Lv0PDaEwCZAX1Rm4r5Xi1OZE9tXozuYnnb
> 8cwAnRwg67yL9qjG2Zbwi6kryoD7XcX1
> =c4Pg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>



-- 
Martin Grotzke
http://www.javakaffee.de/blog/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message