2

我在我的一个Ruby on Rails项目中使用Elasticsearch - Bonsai 。所以,到目前为止,事情进展得很顺利。但是,当我们向最终用户推出这个应用程序并且人们开始进入的那一刻,我们注意到单个弹性搜索查询需要 5-7 秒才能响应(对我们来说真的很糟糕)——尽管我们有8-2 倍的 Web测功机到位。

因此,我们决定将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 来获取我得到的数字

好的,所以在阅读了评论并在这里找到了一篇好文章后:如何在一台服务器上配置弹性搜索集群以获得最佳搜索性能我想我已经足够重新构建

最好的,

普奈特

4

2 回答 2

1

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

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

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

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

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

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

于 2016-03-06T03:34:04.580 回答
0

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

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

于 2016-03-05T16:42:06.957 回答