ruby-on-rails - 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调用数据

这表明有很大的理由担心。

我的模型article.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 one server to get the best performace on search我想我已经有足够的东西来重组了

最好的，

普尼特

Answer 1

这里是 Nick 和盆景。如果您通过 support@bonsai.io 与我们的支持团队联系，我们总是很乐意帮助解决性能问题，并且可以访问更多详细的日志来帮助解决这个问题。与此同时，我想我可以在这里分享一些足够通用的建议……

在这种情况下，您的 New Relic 报告中有趣的统计数据是“平均调用(每笔交易):109”。如果我的理解正确的话，您的应用似乎平均每个 Web 请求调用 Elasticsearch 超过 100 次。这似乎异常高。

如果这 3,000 毫秒是所有 100 多个请求的平均值，那么 Elasticsearch 的每个请求大约需要 30 毫秒。这也比我们通常的平均值慢一点，但比单个请求的 3,000 毫秒要合理得多。 (我们可以通过更多私有(private)支持信件与您分享更具体的号码。)

您可能希望专注于减少 Elasticsearch 请求的数量。如果您不能减少请求总数，您可以考虑将它们组合起来以节省每个请求和每个连接的开销。 Bonsai 还支持 HTTP keep-alive，因此您可以重用请求之间的连接，有助于减少初始 TLS 握手的开销。

要整合更新，您可以使用 Bulk API .还有 Multi Search API用于搜索和 Multi Get API对于单个文档获取请求。

如果减少和合并都不可能，那么您可能有一些其他用例对于单独进行所有这些搜索很重要。如果是这种情况，我会建议在 UI 中使用 Ajax 来后加载这些搜索。这样，您的应用可以提供快速的初始响应并向用户显示一些进度，同时逐渐填充其余部分。