lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11522) Suggestions/recommendations to rebalance replicas
Date Mon, 22 Oct 2018 23:55:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message