You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Goncharuk (JIRA)" <ji...@apache.org> on 2017/06/20 09:30:00 UTC
[jira] [Updated] (IGNITE-5551) Optimize service deployment
assignments object
[ 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)