Rails - Elasticsearch（盆景）和Heroku - 性能問題

Question

我正在使用Elasticsearch - 盆景在我的其中一個Ruby on Rails項目。所以，事情進展得很順利。但是，當我們向最終用戶和人們開始使用該應用程序的那一刻，我們注意到一個彈性搜索查詢需要5-7秒的時間才能做出響應（對我們來說真的是糟糕的體驗） - 雖然，我們有8-2x Web Dynos到位。

所以，我們決定升級盆景附加到盆景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} 

及以下的ES調用

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

我的模型下面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 

現在，如果我看的盆景10計劃的Heroku，它給了我20碎片但隨着集羣的當前狀態，它僅使用1個活動主碎片和2個活動碎片。我的腦海中突然出現了一些問題：

1. 增加碎片數量到20會有幫助嗎？
2. 它可以緩存ES查詢 - 你也建議一樣嗎？ - 它有沒有什麼優點和缺點？

請幫我找到減少時間和提高ES工作效率的方法。

UPDATE

這裏的一小段代碼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

你有3個ES節點，最佳性能要求每個節點的至少一個碎片。 Heroku可能會報告其他內容。碎片是ES內部某個索引的屬性，而不是ES集羣本身，因此檢查索引有多少碎片。但即使只有一個分支，你的查詢也不會太慢，可能文檔索引是錯誤的。您提供了關於您的索引，查詢和負載的信息太少。

緩存可能對任何存儲系統都有幫助，缺點和專業人員總是一樣的。

Answer 2

尼克與盆景在這裏。如果您通過support@bonsai.io聯繫我們的支持團隊，我們總是樂於幫助解決性能問題，並且可以訪問更多更詳細的日誌以幫助解決這些問題。與此同時，我想我可以在這裏分享一些足夠一般的建議...

在這種情況下，您的New Relic報告中有趣的統計數字是「Average calls（per txn）：109。」如果我正確地理解了這一點，它看起來應用程序平均每個Web請求對Elasticsearch的調用次數超過100次。這似乎非常高。

如果所有100個以上的請求的平均值爲3,000ms，那麼對Elasticsearch的請求大約需要30毫秒。這也比我們平時的平均速度慢一點，但對於單個請求來說，要比3,000ms更合理。 （我們可以通過更多的私人支持通信與您分享更具體的數字。）

您可能想要關注減少Elasticsearch請求的數量。如果無法減少總請求數量，則可以考慮將它們組合起來以節省每個請求和每個連接的開銷。盆景還支持HTTP保持活動狀態，因此您可以重複使用請求之間的連接，有助於減少初始TLS握手的開銷。

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

如果減少和整合都不可能，那麼您可能有其他一些用例，這對於單獨進行所有這些搜索很重要。如果是這樣的話，我會建議在UI中使用Ajax來後期加載這些搜索。這樣，您的應用就可以提供快速的初始響應，並向用戶展示一些進展，同時逐漸填充其餘部分。