[
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
