具有Heroku的Rails -弹性搜索(Bonsai) -性能问题

Question

我在我的一个Rails项目中使用Elasticsearch - Bonsai。所以，事情进展得非常顺利。但是，当我们向最终用户和用户发布这个应用程序的时候，我们注意到一个elasticsearch查询需要5-7秒的响应时间(对我们来说非常糟糕) --尽管我们已经安装了8-2xWebdynos。

因此，我们决定将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的盆景10计划，它给出了20碎片，但是在当前的集群状态下，它只使用了1个活动主碎片和2个活动碎片。没有几个问题突然出现在我的脑海中：

1. 把碎片数量增加到20个会有帮助吗？
2. 可以缓存ES查询--您也建议这样做吗？--它有Pros和Cons吗？

请帮助我找到减少时间和提高工作效率的方法。

更新

下面是我创建的小代码片段https://jsfiddle.net/puneetpandey/wpbohqrh/2/ (作为参考)，以准确地说明为什么我需要这么多对https://jsfiddle.net/puneetpandey/wpbohqrh/2/的调用

在上面的例子中，我显示了一些计数(在每个复选框元素前面)。为了显示这些计数，我需要获取我通过命中ES得到的数字。

好的，在阅读了评论之后，在这里找到了一篇很好的文章：如何在一台服务器上配置elasticsearch集群以获得最佳搜索性能，我想我已经有足够的时间来重新构建

最好的

普奈

Answer 1

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

在这种情况下，新遗留报告中有趣的统计数据是“平均调用(每个txn)：109”。如果我的理解是正确的，看起来你的应用程序平均每个web请求都有超过100个对Elasticsearch的调用。这似乎不寻常的高。

如果3,000毫秒是所有100+请求的平均值，那么对于Elasticsearch的每个请求大约是30 ms。这也比我们通常的平均速度要慢一些，但是对于一个请求来说，这比3000毫秒要合理得多。(我们可以通过更多的私人支持信函与您分享更多的具体数字。)

您可能需要集中精力减少Elasticsearch请求的数量。如果不能减少总请求，可以考虑合并它们以节省每个请求和每个连接的开销。盆景还支持HTTP保持活动，这样您就可以重用请求之间的连接，从而帮助减少初始TLS握手的开销。

为了巩固更新，您可以使用散装API。还有用于搜索的多搜索API和用于单文档get请求的多Get API。

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

Answer 2

您有3个ES节点，最佳性能要求每个节点至少有一个碎片。Heroku可能还报道了其他的事情。碎片是ES内部特定索引的属性，而不是ES集群本身的属性，因此请检查索引有多少碎片。但是即使有一个片段，您的查询也不应该这么慢，可能文档的索引方式是错误的。您提供的有关索引、查询和负载的信息太少。

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