<local-scheme> <scheme-name>local-cache-default</scheme-name> <autostart>true</autostart> <serializer> <class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name> <init-params> <init-param> <param-type>string</param-type> <param-value>pof-config.xml</param-value> </init-param> </init-params> </serializer> <pre-load>true</pre-load> </local-scheme>
<replicated-scheme> <scheme-name>replicated-default</scheme-name> <thread-count>20</thread-count> <backing-map-scheme> <local-scheme /> </backing-map-scheme> <autostart>true</autostart> <serializer> <class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name> <init-params> <init-param> <param-type>string</param-type> <param-value>pof-config.xml</param-value> </init-param> </init-params> </serializer> </replicated-scheme>
899446 wrote:I would guess the effect you see is because of the cache keys being serialized as the backing map keys would be in binary format.
We've recently switched some of our caches from Local to Replicated schemes. See config below. I would expect no change in "get" performance, since the data will be local to the member. However, we've seen a slight degradation of performance since making the change. The change is small (microseconds), but being a low-latency application we are feeling the affects.
Is there any reason why this would be the case?
A follow-on question: I've specified a POF serializer for the caches. However, I would really prefer not to have the entries stored in a serialized form. Rather, we would see better performance if they were in a deserialized, in-memory state. Is this possible? I understand that removing the <serializer> element will cause the cache to default to using Java Serialization.Replicated caches keep entry values which the local code already saw in Object form. Incoming updates are stored in binary form until they are accessed locally at which point they are going to be replaced with the Java object form. This way you don't pay for deserializing versions of cache values which are never actually accessed. You should be aware though, that multiple threads accessing the same cached value get the same Java object reference so you must not mutate that object, you must clone it before mutating it.
Thanks Rob. It's a shame we don't get more advanced control over this behaviour - our system is very sensitive to read-latency, but doesn't have such high concerns about writes or storage space.If you are are so conscious about read latency so that you would rather take the hit on incoming updates even which are not going to be looked at, then you may try to investigate around replacing the backing map class with something which eagerly deserializes Binary objects put into its entry values.