Question

我的情况是我需要将应用程序（以百万为单位）的文档加载到带有zookeeper的* solr云作为配置同步服务* 。由于大量的文件流量，我对性能问题感到困惑。让我们说我有两个solr运行的分片和两个每个分片的zookeeper主机实例。所以我的方法是这样的：

  var rtr = system.actorOf(Props(new solrCloudActor(zkHost,core)).withRouter(SmallestMailboxRouter(nrOfInstances = 8)))
  //router vector created globally with 8 instances based on some black box tests that single solr instance can utilize 8 threads in parallel for loading.
  .
  ..
  ... 
  val doc:SolrInputDocument = new SolrInputDocument() //repeated million times depending on number of documents and creating docs here
  doc.addfield("key","value")
  .
  ...
  rtr ! loadDoc(doc) // broadcasting the doc here 

class solrCloudActor(zkHost:String,solrCoreName:String) extends Actor{
  val server:CloudSolrServer  = new CloudSolrServer(zkHost)
  server.setDefaultCollection(solrCoreName)
  def recieve{
    case loadDoc(d:SolrInputDocument) => server.add(d)
  }
}

我在这里担心的一些问题：

这种方法是否正确。实际上，当我有单个solr实例并创建了8个路由器矢量实例的httpclient actor 而不是 solrcloud与zookeeper 时，这是有意义的。
当我在队列中有数百万个文档时，使solr加载到峰值所需的最佳线程数是多少。是numofshards x some_optimal_number还是线程数取决于每个核心每个分片的数量或者是平均值：（numofshards x some_optimal_number + numberofcore）/ numberofcore ..
我甚至需要担心并行性吗？我通过提供所有逗号分隔的zookeeper主机来启动的单个solrcloud服务器实例可以负责文档的分发。
如果我完全走错了方向，请提出一个更好的方法来改善表现。

Answer 1

演员数量和线程数不相同。演员在工作时使用来自池中的线程。

可以并发运行的线程数限制为池大小（除非另有特别配置）是动态的，但通常与核心数相匹配。

因此，合理参与者的理想数量与合并线程的数量大致相同。

在理想情况下，池化线程的数量是核心数量。

但是......我们不是生活在一个理想的世界里。一个理想的世界没有阻塞操作，没有网络或其他IO延迟，没有其他进程在机器上竞争资源等等。

在一个非理想的（a.k.a真实）世界。最佳数量取决于您的代码库和您的特定环境。只有你和你的探查者可以回答那个。

在solr云上加载文档所需的最佳actor实例（线程）数

1 个答案: