-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin,
On 2/15/2011 3:46 PM, Martin Grotzke wrote: > 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.). Okay, so you *do* take data fingerprints. How well does that perform? I suppose the balance of being able to replicate the objects with very little in the way of /coding/ overhead has its advantaged, but that seems like a lot of work to do after every request just to see if replication is necessary. > 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. Do you re-replicate the entire session or just the object that was accessed? Or, are you saying that you only re-fingerprint the objects that are accessed during a particular request? > 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. Serializing objects after a request is complete delays the return of the request processing thread to the thread pool. More threads will be required to handle a particular user load and performance across the webapp will suffer. Is that more specific and useful? My assertion is that object changes are more easily detectable (or, better yet, /knowable/) by the webapp itself and it's trivial to notify the replication manager that an object needs to be re-replicated using HttpSession.setAttribute. > 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) That's interesting. Is there one thread that manages all replication? Under load, does it ever fall behind? I can imagine a work queue getting longer with each request... > - 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. I would think this would be very application-specific: of course a light session or trivially-serialized session-stored objects will not incur much of a penalty. > 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. My argument is that the webapp knows it's own business :) > 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. That's a fair point. >> 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. Thanks for the details. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1b9oIACgkQ9CaO5/Lv0PD+jQCfSeKNoJGNNhS7mk/tuUOXNHEf YR4AoKy2jygC/u/wB1oGdUQZzbpSBre6 =Yrru -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
