You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2014/11/07 17:22:33 UTC

[jira] [Updated] (SOLR-6717) Indexing performance when sending updates to incorrect core is terrible

     [ https://issues.apache.org/jira/browse/SOLR-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shawn Heisey updated SOLR-6717:
-------------------------------
    Description: 
A user on the mailing list was sending document updates to a random node/core in his SolrCloud.  Performance was not scaling anywhere close to what was expected.  Basically, indexing performance was not scaling when adding shards and servers.

As soon as the user implemented a smart router that was aware of the cloud structure and could send to the proper shard leader, performance scaled exactly as expected.  It's not Java code, so CloudSolrServer was not an option.

There will always be some overhead involved when sending update requests to the wrong shard replica, but hopefully something can be done about the performance hit.

http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201411.mbox/%3CCALswpfDQT4+_eZ6416gMyVHkuhdTYtxXxwxQabR6xeTZ8Lx=tQ@mail.gmail.com%3E


  was:
A user on the mailing list was sending document updates to a random node/core in his SolrCloud.  Performance was not scaling anywhere close to what was expected.  Basically, indexing performance was not scaling when adding shards and servers.

As soon as the user implemented a smart router that was aware of the cloud structure and could send to the proper shard leader, performance scaled exactly as expected.  It's not Java code, so CloudSolrServer was not an option.

There will always be some overhead involved when sending update requests to the wrong shard replica, but hopefully something can be done about the performance hit.

(I will include a link to the apache mail archives as soon as the summary message becomes available).



> Indexing performance when sending updates to incorrect core is terrible
> -----------------------------------------------------------------------
>
>                 Key: SOLR-6717
>                 URL: https://issues.apache.org/jira/browse/SOLR-6717
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 4.10.2
>            Reporter: Shawn Heisey
>             Fix For: 5.0, Trunk
>
>
> A user on the mailing list was sending document updates to a random node/core in his SolrCloud.  Performance was not scaling anywhere close to what was expected.  Basically, indexing performance was not scaling when adding shards and servers.
> As soon as the user implemented a smart router that was aware of the cloud structure and could send to the proper shard leader, performance scaled exactly as expected.  It's not Java code, so CloudSolrServer was not an option.
> There will always be some overhead involved when sending update requests to the wrong shard replica, but hopefully something can be done about the performance hit.
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201411.mbox/%3CCALswpfDQT4+_eZ6416gMyVHkuhdTYtxXxwxQabR6xeTZ8Lx=tQ@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org