[
https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091586#comment-16091586
]
Alexey Kukushkin edited comment on IGNITE-5551 at 7/18/17 2:19 PM:
-------------------------------------------------------------------
Changes:
* http://reviews.ignite.apache.org/ignite/review/IGNT-CR-236
* git diff 37a8291 7a20751 in https://github.com/ggprivate/ggprivate.git
* No changes in .NET in spite of PlatformServices changes since the binary
format did not change. I ran all the .NET Services tests and they passed.
was (Author: kukushal):
Changes:
* http://reviews.ignite.apache.org/ignite/review/IGNT-CR-236
* git diff 7a20751 37a8291 in https://github.com/ggprivate/ggprivate.git
* No changes in .NET in spite of PlatformServices changes since the binary
format did not change. I ran all the .NET Services tests and they passed.
> 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
> Assignee: Alexey Kukushkin
> Priority: Critical
> 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)
