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

回答

相關問題