ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Goncharuk (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
Date Tue, 20 Jun 2017 09:30:00 GMT

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

Alexey Goncharuk updated IGNITE-5551:
-------------------------------------
    Description: 
1) The deployment assignment is stored using a map [node ID -> number of assigned services].
However, this assignment is not very effective for cases when service configuration is (maxPerCluster
= 0, maxPerNode > 0), because in this case, we can avoid assignment recalculation at all.
The assignment for this case may look like (eachNode=N). In this case, the assignment does
not change and we can effectively skip it during the reassign loop.

2) We store zero assignment counters, which does not make sense at all - if there are no service
deployments for a node, there should be no corresponding entry in the map at all. The size
of assignments for (maxPerCluster > 0) configurations is O(number of nodes in the cluster),
but it should be O(maxPerCluster).

3) If an assignment did not change, we should not commit the assignment transaction - this
is redundant

4) Perhaps, it also makes sense to calculate several assignments at once and do a putAll commit
instead of single puts - this should also decrease the assignment calculation latency

  was:
1) The deployment assignment is stored using a map [node ID -> number of assigned services].
However, this assignment is not very effective for cases when service configuration is (maxPerCluster
= 0, maxPerNode > 0), because in this case, we can avoid assignment recalculation at all.
The assignment for this case may look like (eachNode=N). In this case, the assignment does
not change and we can effectively skip it during the reassign loop.

2) We store zero assignment counters, which does not make sense at all - if there are no service
deployments for a node, there should be no corresponding entry in the map at all. The size
of assignments for (maxPerCluster > 0) configurations is O(number of nodes in the cluster),
but it should be O(maxPerCluster).

3) If an assignment did not change, we should not commit the assignment transaction - this
is redundant


> Optimize service deployment assignments object
> ----------------------------------------------
>
>                 Key: IGNITE-5551
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5551
>             Project: Ignite
>          Issue Type: Improvement
>          Components: managed services
>    Affects Versions: 1.7
>            Reporter: Alexey Goncharuk
>             Fix For: 2.2
>
>
> 1) The deployment assignment is stored using a map [node ID -> number of assigned
services]. However, this assignment is not very effective for cases when service configuration
is (maxPerCluster = 0, maxPerNode > 0), because in this case, we can avoid assignment recalculation
at all. The assignment for this case may look like (eachNode=N). In this case, the assignment
does not change and we can effectively skip it during the reassign loop.
> 2) We store zero assignment counters, which does not make sense at all - if there are
no service deployments for a node, there should be no corresponding entry in the map at all.
The size of assignments for (maxPerCluster > 0) configurations is O(number of nodes in
the cluster), but it should be O(maxPerCluster).
> 3) If an assignment did not change, we should not commit the assignment transaction -
this is redundant
> 4) Perhaps, it also makes sense to calculate several assignments at once and do a putAll
commit instead of single puts - this should also decrease the assignment calculation latency



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message