[ https://issues.apache.org/jira/browse/SOLR-11522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659852#comment-16659852 ]
Noble Paul commented on SOLR-11522: ----------------------------------- bq. why aren't all the callers of _get just using toMap ... {{toMap()}} is extremely expensive and must be avoided if possible bq. converting hte entire object to a Map would be just as efficient as only "writing" that single entry, NO. A Map is a very expensive object . The writeMap() is just multiple method calls (no Objects are created). it doesn't necessarily "write" to anything. Essentially, the cost of a {{MapWriter._get("key")}} is same as a {{NamedList#get("key")}} bq...at least 3 times slower then if the test just did something like... Yes. But the cost is negligible. get operations are pretty cheap (they are only as costly as a {{NamedList.get()}} ) .there are no new Objects created . It was done for readability of tests. bq.If the answer is: "Because we want impls of MapWriter to be able to provide a more efficient impl." then why have such a terrible inefficient default impl at all? The default impl is generic .(it is not "inefficient", it is actually quite performant.) . If the MapWriter is backed by a Map, the lookup is slightly faster . O(log\(n)) vs O\(n) bq.At the very least, this method should have a more descriptive name and better javadocs (as should Utils.getObjectByPath that makes it clear what the performance tradeoffs are here. The better solution is to move the {{_get*}} methods to another interface and {{MapWriter}} implement that . Yes, better javadocs are definitely required > Suggestions/recommendations to rebalance replicas > ------------------------------------------------- > > Key: SOLR-11522 > URL: https://issues.apache.org/jira/browse/SOLR-11522 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling > Reporter: Noble Paul > Priority: Major > > It is possible that a cluster is unbalanced even if it is not breaking any of > the policy rules. Some nodes may have very little load while some others may > be heavily loaded. So, it is possible to move replicas around so that the > load is more evenly distributed. This is going to be driven by preferences. > The way we arrive at these suggestions is going to be as follows > # Sort the nodes according to the given preferences > # Choose a replica from the most loaded node ({{source-node}}) > # try adding them to the least loaded node ({{target-node}}) > # See if it breaks any policy rules. If yes , try another {{target-node}} > (go to #3) > # If no policy rules are being broken, present this as a {{suggestion}} . > The suggestion contains the following information > #* The {{source-node}} and {{target-node}} names > #* The actual v2 command that can be run to effect the operation > # Go to step #1 > # Do this until the a replicas can be moved in such a way that the {{target > node}} is more loaded than the {{source-node}} -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org