ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-2721) Optimize ATOMIC cache request/responses.
Date Thu, 25 Feb 2016 08:52:18 GMT
Vladimir Ozerov created IGNITE-2721:
---------------------------------------

             Summary: Optimize ATOMIC cache request/responses.
                 Key: IGNITE-2721
                 URL: https://issues.apache.org/jira/browse/IGNITE-2721
             Project: Ignite
          Issue Type: Sub-task
          Components: cache
    Affects Versions: 1.5.0.final
            Reporter: Vladimir Ozerov
            Assignee: Ilya Lantukh
            Priority: Critical
             Fix For: 1.6


Our request/responses for ATOMIC cache has lots of fields which are normally unused.
To give an idea on possible optimizations lets look closely on GridNearAtomicUpdateRequest:
* {{futVer}} - could be converted to int
* {{syncMode}} - why do we pass it? Can it be derived from cache config?
* {{op}} - can it be derived form request?
* Entry processors and invoke arguments - can be moved to extras, or separate request class
can be created for them.
* Conflict data - usually null, must be moved to extras
* Expiry policy - must be moved to extras.
* {{filter}} - only one filter is ever passed - when we need to compare existing value. Lets
pass the value instead!
* Lots of flags - can be written as a single byte. Though, it's priority is not so high.
* {{topVer}} - could easily be inlined to save allocations and network traffic. 

As a result of this investigation we must create a list of optimizations to be performed and
prioritize them. Then we should implement them one by one, keeping them merged in a separate
branch (not master!) until we are sure that we did everything we can.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message