[jira] [Updated] (IGNITE-2721) Optimize ATOMIC cache request/responses.

["Vladimir Ozerov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Ozerov updated IGNITE-2721:
------------------------------------
    Labels: performance  (was: )

> 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
>            Priority: Critical
>              Labels: performance
>             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)