multithreading - 在Solr Cloud上加载文档所需的最佳Actor实例(线程)数

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 的路由器矢量实例而不是使用zookeeper 的 solrcloud时，这才有意义。

当我在队列中有数百万个文档时，使solr达到峰值所需的最佳线程数是多少？是numofshards x some_optimal_number还是线程数取决于每个内核的每个分片还是平均数:( numofshards x some_optimal_number + numberofcore)/numberofcore ..

我什至需要担心并行性吗？我可以通过提供所有以逗号分隔的zookeeper主机启动的单个solrcloud服务器实例来处理文档的分发。

如果我完全朝错误的方向发展，请提出一种改进性能的更好方法。

Answer 1

Actor的数量和线程的数量是，而不是。角色在有工作要做时就使用池中的线程。

可以并发运行的线程数限制为池大小，除非动态配置，否则池大小是动态的，但通常与内核数匹配。

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

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

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

在非理想的世界(又称真实世界)中。最佳数量取决于您的代码库和您的特定环境。只有您和您的分析器才能回答该问题。