[jbosscache-dev] VAM in JDBCCacheLoader : performance numbers and analysis

[Galder Zamarreno]

Hi,

I've been doing some performance tests for JDBCCacheLoader with both normal Java Serialization and VersionAwareMarshaller, using the existing JDBCCacheLoaderPerfTest.

The results I got back were quite suprising. Executing a test consisting of 10 threads (each thread interacts with a single node) and each thread adds 100 key/value pairs to their node. Tests showed that normal serialization was something like 15 times faster than VAM when it came to writes. For reads, normal serialization was still 4 times faster. We're talking about String/String key value pairs here.

Looking a bit deeper with the profiler, I have seen that TreeCacheMarshaller200 takes ages marshalling a map containing string key/value pairs. Is this expected? We're adding quite a few things to a simple String/String map, such as versioning and reference information. Compared to standard writeObject in HashMap, TreeCacheMarshaller200 spends quite a bit of time mantaining/updating a reference map. 

In this case, for a single put, each key and value values are different (key0/value0 key1/value1 key2/value2...), maintaining references becomes an extra overhead as the reference maps are created for each request to marshall the original map. However, I can see the point why it was done (avoid extra serialization and reduce the amount of data in the wire). 

I had a quick thought about caching reference data so that it survived several requests to marshal data, but it's probably a bad idea as this cache would become a contention for concurrent marshalling and increase the memory requirements. Has anyone been this route before? I think it might only produce positive results in such specific test as this.

I tried JBoss serialization and the results were even worse. What type of Objects is JB serialization recommended for? Is it user defined ones?

I have attached JProfiler files from all three tests and also a CVS diff in case anyone wants to have a quick glance. Note that even though there's 1000 calls to marshallMap, as threads add new key/value pairs, the data read-to-be-updated increases and hence the number of items to iterate through in the map.

FYI, useRegionBasedMarshalling is set to false. 

Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat

IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JBCACHE-897-serialization.java-10-100.jps
Type: application/octet-stream
Size: 606154 bytes
Desc: JBCACHE-897-serialization.java-10-100.jps
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20061227/0656985e/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JBCACHE-897-serialization.jboss-10-100.jps
Type: application/octet-stream
Size: 852060 bytes
Desc: JBCACHE-897-serialization.jboss-10-100.jps
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20061227/0656985e/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Head-serialization.java-10-100.jps
Type: application/octet-stream
Size: 571199 bytes
Desc: Head-serialization.java-10-100.jps
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20061227/0656985e/attachment-0002.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.27.12.2006.txt
Url: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20061227/0656985e/attachment.txt