Rails - Elasticsearch (Bonsai) with Heroku - 性能問題

Question

我在我的Ruby on Rails項目之一中使用Elasticsearch - Bonsai 。 所以，到目前為止，事情進展得非常順利。 但是，當我們向最終用戶推出這個應用程序並且人們開始進來時，我們注意到單個 elasticsearch 查詢需要 5-7 秒來響應（對我們來說真的很糟糕的體驗）——盡管我們有8-2x Web Dynos就位。

因此，我們決定將Bonsai附加組件升級到Bonsai 10並添加了NewRelic附加組件（以關注單個查詢需要多長時間來響應）

以下是我們的環境設置：

Ruby: 2.2.4
Rails: 4.2.0
elasticsearch: 1.0.15
elasticsearch-model: 0.1.8

因此，我們再次將數據導入 Elasticsearch，這是我們的ElasticSearch集群健康狀況：

pry(main)> Article.__elasticsearch__.client.cluster.health
=> {"cluster_name"=>"elasticsearch",
    "status"=>"green",
    "timed_out"=>false,
    "number_of_nodes"=>3,
    "number_of_data_nodes"=>3,
    "active_primary_shards"=>1,
    "active_shards"=>2,
    "relocating_shards"=>0,
    "initializing_shards"=>0,
    "unassigned_shards"=>0,
    "delayed_unassigned_shards"=>0,
    "number_of_pending_tasks"=>0,
    "number_of_in_flight_fetch"=>0}

下面是NewRelic的ES調用數據

這表明一個很大的理由擔心。

我的模型文章.rb如下：

class Article < ActiveRecord::Base
  include Elasticsearch::Model

  after_commit on: [:create] do
    begin
      __elasticsearch__.index_document
    rescue Exception => ex
      logger.error "ElasticSearch after_commit error on create: #{ex.message}"
    end
  end

  after_commit on: [:update] do
    begin
      Elasticsearch::Model.client.exists?(index: 'articles', type: 'article', id: self.id) ? __elasticsearch__.update_document :     __elasticsearch__.index_document
    rescue Exception => ex
      logger.error "ElasticSearch after_commit error on update: #{ex.message}"
    end
  end

  after_commit on: [:destroy] do
    begin
      __elasticsearch__.delete_document
    rescue Exception => ex
      logger.error "ElasticSearch after_commit error on delete: #{ex.message}"
    end
  end

  def as_indexed_json(options={})
    as_json({
      only: [ :id, :article_number, :user_id, :article_type, :comments, :posts, :replies, :status, :fb_share, :google_share, :author, :contributor_id, :created_at, :updated_at ],
      include: {
        posts: { only: [ :id, :article_id, :post ] },
      }
    })
  end
end

現在，如果我查看Heroku的 BONSAI 10 計划，它給了我20 個分片，但在集群的當前狀態下，它僅使用 1 個活動主分片和 2 個活動分片。 我的腦海里突然冒出幾個問題：

1. 將分片數量增加到 20 會有幫助嗎？
2. 可以緩存 ES 查詢——您是否也有同樣的建議？ -- 它有什么優點和缺點嗎？

請幫助我找到可以減少時間並使 ES 工作更有效率的方法。

更新

這是小代碼片段https://jsfiddle.net/puneetpandey/wpbohqrh/2/ ，我創建了（作為參考）來確切說明為什么我需要對ElasticSearch 進行如此多的調用

在上面的示例中，我顯示了一些計數（在每個復選框元素之前）。 為了顯示這些計數，我需要通過點擊 ES 獲取我得到的數字

好的，在閱讀評論並在此處找到一篇好文章后： How to config elasticsearch cluster on a server to get the best performance on search我想我有足夠的時間重新構建

最好的事物，

普尼特

Answer 1

尼克和盆景在這里。 如果您通過 support@bonsai.io 與我們的支持團隊聯系，我們總是很樂意幫助解決性能問題，並且可以訪問更詳細的日志來幫助解決這個問題。 與此同時，我想我可以在這里分享一些足夠通用的建議......

在這種情況下，New Relic 報告中有趣的統計數據是“平均調用次數（每筆交易）：109”。 如果我理解正確的話，看起來您的應用程序對每個 Web 請求的 Elasticsearch 調用平均超過 100 次。 這似乎異常高。

如果所有 100 多個請求的平均時間為 3,000 毫秒，那么每個發送到 Elasticsearch 的請求大約需要 30 毫秒。 這也比我們通常的平均值慢一點，但比單個請求的 3,000 毫秒合理得多。 （我們可以通過更多的私人支持信件與您分享更具體的數字。）

您可能希望專注於減少 Elasticsearch 請求的數量。 如果您不能減少總請求數，您可以考慮將它們組合起來以節省每個請求和每個連接的開銷。 Bonsai 還支持 HTTP keep-alive，因此您可以重用請求之間的連接，幫助減少初始 TLS 握手的開銷。

為了整合更新，您可以使用Bulk API 。 還有用於搜索的Multi Search API和用於單文檔獲取請求的Multi Get API 。

如果減少和合並都不可能，那么您可能還有其他一些對單獨進行所有這些搜索很重要的用例。 如果是這種情況，我建議在 UI 中使用 Ajax 來后加載這些搜索。 這樣，您的應用程序可以提供快速的初始響應並向用戶顯示一些進度，同時逐漸填充其余部分。

Answer 2

您有 3 個 ES 節點，最佳性能要求每個節點至少有一個分片。 Heroku 可能會報告其他內容。 分片是 ES 內部某個索引的屬性，而不是 ES 集群本身，所以檢查你的索引有多少分片。 但即使只有一個分片，您的查詢也不應該如此緩慢，可能是文檔以錯誤的方式編入索引。 您提供的有關索引、查詢和負載的信息太少。

緩存可能有幫助，就像任何存儲系統一樣，優缺點總是一樣的。