Solr云性能

我想评估我的项目之一，我需要检查我的应用程序的tps（每秒交易量）的可伸缩性之一。我已将1台AWS服务器上的solr配置为独立应用程序，为我的查询提供了大约8000的搜索查询tps。为了测试可伸缩性，我已经在两台AWS服务器上分别记录了相同的数据，每台服务器有2.5千万条记录。当我尝试使用与之前相同的查询查询集群时，它给了我一个〜2500的tps。我的理解是tps应该在集群中增加，因为这是两台不同的机器，它们将执行单独的I/O操作。我正在使用solr提供的查询REST端点。我没有配置任何单独的负载平衡器，因为solr文档说默认情况下solr云会以循环方式执行负载平衡。感谢任何帮助我验证我的理解。Solr云性能

来源

2015-12-21 Anshul Sharma

你如何查询集群？当你从一个节点转到两个时，你的查询将不得不从你正在查询的节点分发，导致更多的网络吞吐量。有趣的问题通常是当引入节点3,4,5等时发生的情况，因为从1到2引入了处理分布式查询的所有复杂性。 – MatsLindh

我正在通过solr提供的/ select REST端点来查询集群。您认为网络延迟可能会降低性能吗？ –

但是你使用群集感知客户端吗？否则，Solr将执行从正在查询的服务器的路由以查找包含该文档的节点，因此它将在Solr方面具有（额外的）网络开销。尽管先前可以通过请求 - 服务器 - 响应来提供请求，但现在是请求 - 服务器 - 请求 - 服务器 - 响应 - 服务器 - 响应，并在合适的地方合并结果。 – MatsLindh

你看到的是具有Solr的路由（也可能合并）跨群集的要求相比，从你查询服务器只是回答本地查询的开销。

在查询一个单一的Solr服务器，该服务器拥有所有可用的本地磁盘上的数据，让您的查询可以在服务器中，并且不必询问数据的任何其它服务器进行处理。在服务器上查询collection1会给接近请求流：当你介绍其他服务器到群集，但仍保持询问的第一个服务器

client -> request -> server (disk) -> response -> client

，该服务器可能要问有关数据的其他服务器，以及 - 除非您正在与之交谈的服务器（第一个）具有您要查询的集合中的所有文档。

所以我们可以说，所有的collection2的文档所在的第二台服务器上，但你还是谈话的第一台服务器：

client -> request -> server1 
      (doesn't have the documents, so it'll ask the node that has) 
         server1 -> request -> server2 
         server1 <- response <- server2 
client <- response <- server1

正如你所看到的，要求现在依赖于一个服务器1和服务器2之间的全新请求，并且随着检索复杂度的提高，吞吐量下降。 API仍然是一样的，但是Solr内部发生的事情已经引入了请求背后的另一层请求。

那么，为什么不使用群集感知客户端（例如SolrJ与CloudSolrClient）帮助？它从ZooKeeper检索集群配置开始，然后直接查询第二台服务器 - 因为它可以看到collection2住在server2上。

client -> request -> zookeeper -> response -> client 
client -> request -> server2 -> response -> client

当你后对方让许多查询，只有第二行重复（如你当你标杆，索引或应用程序中的重负载查询做），这样下次查询可以除非发生错误，没有首先询问动物园管理员来解决：

client -> request -> server2 -> response -> client

这就是为什么你会再次见到巨大的吞吐量，当你使用云感知客户端。

但还有更多的情况，这是当收不只是一个单一的服务器上，并会再次影响到你的吞吐量会发生什么。服务器2，服务器3和服务器4上存在collection3，并且在服务器之间分割（意味着每个服务器只有一部分索引，例如33.3 ..每个服务器上的文件）的％

client -> server1 
      server1 -> server2 | parallel 
        <-   | 
      server1 -> server3 | 
        <-   | 
      server1 -> server4 | 
        <-   | 
       (merge responses from server2, server3 and server4 
       and return the new, sorted response, cutting it at 
       the number of rows to return) 
client <- server1

云感知客户端可以跳过查询Server1和直接问服务器2，节省一个请求（或如果它真的想，查询节点并行本身并合并回应，但我认为目前没有任何客户会这样做）。

最后一个问题是关于如果客户需要云感知，您可以如何扩展 - 这不需要。它会节省往返时间，但是由于在本地询问磁盘和必须通过网络进行查询之间的巨大变化，您会看到数字发生了很大变化。如果向混合添加另一台服务器并仍然查询第一个Solr节点，则吞吐量将保持不变 - 它不会进一步下降。查询收集结果时，只需查询server3而不是server2。

希望解释你看到的数字！

来源

2015-12-22 08:57:42 MatsLindh

回答

相关问题