Distributed Scheme vs Local Scheme - Execution Time

Question

Hello,
     I am retrofitting an existing application to use Coherence. This application uses one of the JDK's implementations of the Map interface to store a large number of objects. I have modified the application to use Coherence's NamedCache.
     I am running a test case in a single node cluster (only one JVM). When I configure the cache to use a local scheme my test case executes in 105 milliseconds. When I configure the cache to use a distributed scheme my test case executes in 72000 milliseconds. I am surprised by this since there should not be any network traffic in a single node cluster.
     Would you please help me to understand this? I have included the Coherence cache configuration below.
     <cache-config>
          <caching-scheme-mapping>
               <cache-mapping>
                    <cache-name>*</cache-name>
                    <!--scheme-name>LocalCache</scheme-name-->
                    <scheme-name>DistributedCache</scheme-name>
               </cache-mapping>
          </caching-scheme-mapping>
          <caching-schemes>
               <distributed-scheme>
                    <scheme-name>DistributedCache</scheme-name>
                    <service-name>DistributedCache</service-name>
                    <backing-map-scheme>
                         <local-scheme>
                              <scheme-ref>LocalCache</scheme-ref>
                         </local-scheme>
                    </backing-map-scheme>
                    <backup-count>0</backup-count>
                    <autostart>true</autostart>
               </distributed-scheme>
               <local-scheme>
                    <scheme-name>LocalCache</scheme-name>
               </local-scheme>
          </caching-schemes>
     </cache-config>
     Thank you,
     R. Vaessen

Answer 1

Hi Robert,
     according to question about parallel-aggregators this post from Dimitri
     there is a change request (COH-1013) about it.
     However, if you are concerned only about network transmission latency, you should be aware, that it will probably not improve that.
     The serialized format of the cache entry is serialized on the client who puts the data in the cache. This serialized form travels to the primary cache server node (which sends it over to the backups), and the primary node stores it in this form.
     When someone requests that entry, the same serialized form is sent back to the requestor, so getting and putting objects do not mean any serialization/deserialization in the cache servers.
     If there are indexes defined on the cache, then the serialized form is also deserialized upon putting it into the backing map.
     If filters or aggregators or entry-processors are executed on the entries which do not have indexes to be leveraged, then the serialized form of candidate entries is deserialized.
     If you wanted to store entries in object form and serialize it every time it is sent to the client, you would see a performance decrease, and probably a negative effect on GC as well, compared to the current implementation, if you only put and get values to the cache.
     Also, entries in object form consume more memory than they do in serialized form.
     Therefore the only advantage which storing entries in object form is experienced when you want to execute queries or aggregators over non-indexed attributes or entry-processors, where in this case you do not have to pay the cost of deserialization of each entry upon executing the evaluate() method of the filter or upon getting the value from the entry.
     If you want, you can achieve this effect even currently, but at a very large memory cost: you can create a method which returns the object itself, and index that method with a reflection extractor and use an index aware filter and the QueryMap.extract method to access the object in the index instead of the entry itself. Practically you should not do that, if possible, due to the additional memory cost.
     Best regards,
     Robert