IMap.get operation performance for key that does not exist

128 views
Skip to first unread message

Alex

unread,
Aug 23, 2012, 7:32:07 AM8/23/12
to haze...@googlegroups.com
Hi,

I tested the scenario that certain node in cluster requests from IMap key that does not exist. I make sure that this key has is PartitionAware and should be local to the calling node. What I see that get method performance in this case is 8 times slower than if key exists in Map. I did some profiling and code analysis and I see that in case that key is not found locally network call is made to look for the key. Can you please suggest if this is by design behavior or issue that could be fixed?

Thank you in advance,

Alex

Enes Akar

unread,
Aug 24, 2012, 7:51:05 AM8/24/12
to haze...@googlegroups.com
- Do you have near-cache enabled?
- How do you know "the key is local to calling node" ? You can know owner partition not the node.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/2uTo3QeJdeQJ.
To post to this group, send email to haze...@googlegroups.com.
To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.

Alex

unread,
Aug 25, 2012, 12:12:10 PM8/25/12
to haze...@googlegroups.com
Hi,

I have near cache enabled, but it does not matter since there are no value with such a key in Map. As for your question about partition: I tested this scenario even with one HZ node, so it should own all partitions. And still I can see in Debugger and Profiler that there is an attempt to perform remote search.

Alex

Enes Akar

unread,
Aug 27, 2012, 2:59:36 AM8/27/12
to haze...@googlegroups.com
Hi Alex;
If you have near-cache than it is possible that "get where key exists" perform better than "get where key does not exist" as the value is directly served from near cache.

Sorry I do not understand what you mean by "attempt to perform remote search", how did you detect this?

On Sat, Aug 25, 2012 at 7:12 PM, Alex <avak...@gmail.com> wrote:
Hi,

I have near cache enabled, but it does not matter since there are no value with such a key in Map. As for your question about partition: I tested this scenario even with one HZ node, so it should own all partitions. And still I can see in Debugger and Profiler that there is an attempt to perform remote search.

Alex


On Friday, August 24, 2012 2:51:05 PM UTC+3, Enes Akar wrote:
- Do you have near-cache enabled?
- How do you know "the key is local to calling node" ? You can know owner partition not the node.

On Thu, Aug 23, 2012 at 2:32 PM, Alex <avak...@gmail.com> wrote:
Hi,

I tested the scenario that certain node in cluster requests from IMap key that does not exist. I make sure that this key has is PartitionAware and should be local to the calling node. What I see that get method performance in this case is 8 times slower than if key exists in Map. I did some profiling and code analysis and I see that in case that key is not found locally network call is made to look for the key. Can you please suggest if this is by design behavior or issue that could be fixed?

Thank you in advance,

Alex

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/2uTo3QeJdeQJ.
To post to this group, send email to haze...@googlegroups.com.
To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/UydS_HTHQNIJ.

Alex

unread,
Aug 28, 2012, 11:10:52 AM8/28/12
to haze...@googlegroups.com
Hi,

I looked at the code of ConcurrentMapManager inner class MGet. at the end of get operation I see:

            Object value = objectCall(CONCURRENT_MAP_GET, name, dataKey, null, timeout, -1);
            if (value instanceof AddressAwareException) {
                rethrowException(request.operation, (AddressAwareException) value);
            }

As you can see there are no validation that key if it exists should be on local node.

From results of small comparison between get for key that exists and ones that are missing - I can see that get operation with key that does not exist is 7-8 times more expensive.

Alex

Enes Akar

unread,
Aug 29, 2012, 3:31:20 AM8/29/12
to haze...@googlegroups.com
This difference can be due:
If key exists and refers to local node, then value is directly served.
But if key does not exist, (after it is queried lock-free); it is also queried under lock.

There is the same logic in ConcurrentHashMap implementation:

   /* Specialized implementations of map methods */

        V get(Object key, int hash) {
            if (count != 0) { // read-volatile
                HashEntry<K,V> e = getFirst(hash);
                while (e != null) {
                    if (e.hash == hash && key.equals(e.key)) {
                        V v = e.value;
                        if (v != null)
                            return v;
                        return readValueUnderLock(e); // recheck
                    }
                    e = e.next;
                }
            }
            return null;
        }


To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/372brjH88wsJ.

Alex

unread,
Sep 2, 2012, 4:21:49 AM9/2/12
to haze...@googlegroups.com
Hi,

I did additional Profiling and I see that overhead is coming from objectCall as I mentioned in my previous post. See attached picture for details.

Alex
Hazelcast-Search Key that does not exist.png
Reply all
Reply to author
Forward
0 new messages