You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2019/04/24 18:07:00 UTC

[jira] [Created] (GEODE-6703) FilterRoutingInfo.readInternalDistributedMember allocations could be optimized

Darrel Schneider created GEODE-6703:
---------------------------------------

             Summary: FilterRoutingInfo.readInternalDistributedMember allocations could be optimized
                 Key: GEODE-6703
                 URL: https://issues.apache.org/jira/browse/GEODE-6703
             Project: Geode
          Issue Type: Improvement
          Components: serialization
            Reporter: Darrel Schneider


In running a partitioned region client/server put benchmark (with 2 servers and redundancy of 1), I saw that about 8% of the memory allocated on the server was in FilterRoutingInfo.readInternalDistributedMember. FilterRoutingInfo may deserialize multiple InternalDistributedMembers and deserializes an FilterInfo for each one BUT the only one it cares about is the one that is equal to its one id. It just throws away the others. It is possible that an optimization should happen on the sender. If we know when we are sending the FilterRoutingInfo who we were sending it to, then we could just serialize the FilterInfo for their id. This might be hard to do. At a high level we know who we are sending a message to but sometimes we serialize a message once and then send it to multiple peers.

But another way to optimize this code is check the serialized bytes on the receiver for equality with our id. If they are not equal then we can just skip them. If they are equal then we can just use our id as the canonical id. I prototyped this solution in: 

2b58f68c59ecdbd4bfdf8535bb5954d7c1f54a36

It uses a static AtomicReference to remember myId and its serialized form. Since we get myId from the cache, it might be better to have it also cache the serialized form of myId.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)