Rails - 使用 Heroku 的 Elasticsearch (Bonsai) - 性能问题

Question

我在我的一个 Ruby on Rails 项目中使用 Elasticsearch - Bonsai。 所以，到目前为止，事情进展得很顺利。但是，当我们向最终用户推出这个应用程序并且人们开始进来的那一刻，我们注意到单个弹性搜索查询需要 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 工作效率的方法。

更新

这是我创建的小代码 sn-p https://jsfiddle.net/puneetpandey/wpbohqrh/2/（作为参考），以准确说明为什么我需要如此多地调用 ElasticSearch

在上面的示例中，我显示了几个计数（在每个复选框元素的前面）。为了显示这些计数，我需要通过点击 ES 来获取我得到的数字

好的，所以在阅读了 cmets 并在这里找到了一篇好文章后：How to config elasticsearch cluster on one server to get the best performace on search 我想我已经足够重新构建了

最好的，

普奈特

Answer 1

您有 3 个 ES 节点，最佳性能要求每个节点至少有一个分片。 Heroku 可能会报告其他内容。分片是 ES 内部某个索引的属性，而不是 ES 集群本身，所以请检查您的索引有多少分片。但是即使使用一个分片，您的查询也不应该那么慢，可能是文档的索引方式错误。您提供的有关索引、查询和负载的信息太少。

缓存可能会有所帮助，就像任何存储系统一样，缺点和优点总是相同的。

Answer 2

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

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

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

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

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

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