tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tuning session replication on clusters
Date Fri, 07 Sep 2012 18:07:22 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle,

On 9/7/12 12:19 PM, kharper2@oreillyauto.com wrote:
> Chris:
>> Assembling the sessions into a Collection is likely to be very
>> fast, since it's just copying references around: the size of the
>> individual sessions should not matter. Of course, pushing all
>> those bytes to the other servers...
> 
>> Perhaps Tomcat does something like serialize the session to a
>> big binary structure and then sends that (which sounds insane --
>> streaming binary data is how that should be done -- but I haven't
>> checked to code to be sure).
> 
> It appears that tomcat is serializing all the data into a singular 
> structure, rather than a collection of references.

:(

> Watching VisualVM plot heap  usage during replication, it nearly
> doubles (in my test env, this was the only thing running so that
> makes sense).

That certainly sound like Tomcat is chewing-through a lot of heap
space. Without understanding the implementation, I can't comment on
whether or not that is really necessary, but I have to imagine that a
streaming-serialization (or at least buffered, where one session is
serialized at a time and then streamed) would be superior.

> If you're sure Tomcat is only making references, then I'd propose
> there is a problem with the JVM dereferencing the collection
> elements and double-counting the memory used.

It's very unlikely that the JVM is making that kind of mistake. Also,
I haven't looked at a single line of Tomcat's session-distribution
code so I'm not in a position to make accurate assertions about its
implementation.

> Either way, it's enough to make the JVM report a doubling of heap
> usage and a raise to the heap allocation.  As soon as replication
> is done, heap use goes back to normal.  I've attached a screenshot
> to the zip file.

Sounds like your analysis is reasonable. I'll look at your data and
make further comments.

In the meantime, I've heard over the years one particular thing from
people I feel know what they are talking about: don't use HttpSession.

It's not that the servlet spec's session-management isn't useful, it's
that it is very hard to make it scale properly when using most
container-managed clustering implementations. First, it almost always
uses Java Serialization which is not terribly efficient. Second, it is
very coarse-grained: you replicate the entire session or the whole
thing fails (unless you use some vendor-specific tricks like Rainer's
suggestion of suppressing certain attributes). If you have a lot of
data in the session that doesn't *need* to be replicated (like caches,
etc.) then you might be wasting a lot of time.

So, what to use instead? Memcached comes up often as a similar
solution to the problem of clustered temporary data storage. Why
memcached instead of HttpSession clustering? I think about half of the
answer is that when you have to manually push your own data to a
remote cache (instead of allowing the container to handle the
details), you tend to get very frugal with the amount of data you end
up pushing.

We don't use distributed sessions on our product even though (almost)
everything in the session is serializable. Even so, I've thought of
writing a wrapper for certain objects (like caches) that we store in
the session that never need to be replicated (at least not in their
complete forms). I haven't done it because, well, we don't need it.
Stick-sessions with failover is good enough for us, and we don't have
to saturate our network with session-replication chatter.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKN9oACgkQ9CaO5/Lv0PB3LACgsrVWsuWWkb0ckfIPeiNUMoq4
8fcAoIb0FQU/2EsET1AmIHGkX20si4lG
=xKjd
-----END PGP SIGNATURE-----

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


Mime
View raw message