Performance: What's in an cache replication update?

[gregorypierce]

I've been reading the information for TreeCache/JBossCache/JGroups over and over to get a firm understanding on how the technology works because it looks very compelling for a wide variety of applications (outside of the enterprise space), but one thing I haven't been able to figure out for the cache is exactly how much data needs to be moved around during an update? Is this a very chatty protocol at the cache level?

If I have clients A, B, C, and D each holding onto an object:

"TestObject" that has a bunch of attributes, one of which is say the number of walls. If this object changes in A, what has to be transmitted to B, C, and D. Is it just some delta on the property or the entire object graph that TestObject might represent. I'm not entirely clear on how much data I'd be moving around on an object update if I want to set my transaction level such that each property change should be propagated across the clusters.

[gregorypierce]

More specificly - where can I get some information about the number of bytes I'm pushing around?

[belaban]

This is governed by

- transactions: if you use a TX, replication happens at TX commit time

- for async replication: if you use a queue, replication messages are bundled

- TreeCacheAop: only modified attributes are replicated

- JGroups config: if you enable bundling in UDP, changes are batched into bigger messages

You can add the SIZE protocol to JGroups, and it will print out the number of bytes sent/received. In 2.2.9, you can also look at those stats via JMX