ElasticSearch multi percolate performance

Question

У меня есть специальный указатель для перколяторов.
Есть вопросы 3000. Вот типичный запрос:

{ 
    "index": "articles_percolators", 
    "type": ".percolator", 
    "body": { 
     "query": { 
      "filtered": { 
       "query": { 
        "bool": { 
         "should": [ 
          { 
           "query_string": { 
            "fields": [ 
             "title" 
            ], 
            "query": "Cities|urban|urbanization", 
            "allow_leading_wildcard": false 
           } 
          }, 
          { 
           "query_string": { 
            "fields": [ 
             "content" 
            ], 
            "query": "Cities|urban|urbanization", 
            "allow_leading_wildcard": false 
           } 
          }, 
          { 
           "query_string": { 
            "fields": [ 
             "url" 
            ], 
            "query": "Cities|urban|urbanization", 
            "allow_leading_wildcard": false 
           } 
          } 
         ] 
        } 
       }, 
       "filter": { 
        "bool": { 
         "must": [ 
          { 
           "terms": { 
            "feed_id": [ 
             3215, 
             3216, 
             10674, 
             26041 
            ] 
           } 
          } 
         ] 
        } 
       } 
      } 
     }, 
     "sort": { 
      "date": { 
       "order": "desc" 
      } 
     }, 
     "fields": [ 
      "_id" 
     ] 
    }, 
    "id": "562" 
} 

Отображение (массив PHP). Фильтры, анализаторы и tokenizers исключены для краткости:

'index' => 'articles_percolators', 
    'body' => [ 
     'settings' => [ 
      'number_of_shards' => 8, 
      'number_of_replicas' => 0, 
      'refresh_interval' => -1, 
      'analysis' => [ 
       'filter' => [ 
       ], 
       'analyzer' => [ 
       ], 
       'tokenizer'=> [ 
       ] 
      ] 
     ], 
     'mappings' => [ 
      'article' => [ 
       '_source' => ['enabled' => false], 
       '_all' => ['enabled' => false], 
       '_analyzer' => ['path' => 'lang_analyzer'], 
       'properties' => [ 
        'lang_analyzer' => [ 
         'type' => 'string', 
         'doc_values' => true, 
         'store' => false, 
         'index' => 'no' 
        ], 
        'date' => [ 
         'type' => 'date', 
         'doc_values' => true 
        ], 
        'feed_id' => [ 
         'type' => 'integer' 
        ], 
        'feed_subscribers' => [ 
         'type' => 'integer' 
        ], 
        'feed_canonical' => [ 
         'type' => 'boolean' 
        ], 
        'title' => [ 
         'type' => 'string', 
         'store' => false, 
        ], 
        'content' => [ 
         'type' => 'string', 
         'store' => false, 
        ], 
        'url' => [ 
         'type' => 'string', 
         'analyzer' => 'simple', 
         'store' => false 
        ] 
       ] 
      ] 
     ] 
    ] 

Я затем отправить документы в mpercolate API, 100 одновременно. Вот часть (1 документ) по mpercolate запросу:

{ 
    "percolate": { 
     "index": "articles_percolators", 
     "type": "article" 
    } 
}, 
{ 
    "doc": { 
     "title": "Win a Bench Full of Test Equipment", 
     "url": "\/document.asp", 
     "content": "Keysight Technologies is giving away a bench full of general-purpose test equipment.", 
     "date": 1421194639401, 
     "feed_id": 12240778, 
     "feed_subscribers": 52631, 
     "feed_canonical": 1, 
     "lang_analyzer": "en_analyzer" 
    } 
} 

100 изделия обрабатываются в ~1 second на моем MacBook Pro 2,4 ГГц Intel Core i7 (4 ядра, 8 с HT) со всеми ядрами при максимуме:

Это кажется довольно медленным для меня, но у меня нет базы для сравнения.
У меня есть регулярный индекс с тем же отображением (но с 6 осколками) с более чем 3 миллиардами документов (все еще), живущих на одном сервере с 24 core Xeon и 128GB ОЗУ. Такие запросы ищут по всему индексу менее чем 100ms (на горячем сервере).

Есть ли что-то явно неправильное в моей установке, и кто-то еще сравнивал производительность перколяторов? Я ничего не нашел в Интернете об этом ...

Моя ES-версия 1.4.2 с конфигурацией по умолчанию и рабочей нагрузкой полностью связана с процессором.

Редактировать

Поскольку John Petrone's комментарий прямо о тестировании на производственной среде я сделала тест на том же 24 ядра Xeon, как мы используем в производстве. Результат с 8-кратным индексом для перколяции тот же, если даже хуже. Времена где-то между 1 и 1.2, в то время как сетевая латентность ниже, чем у моего ноутбука.
Это, вероятно, объясняется более низкой тактовой частотой для ядра для Xeon - 2.0GHz против 2.4Ghz для i7.

Это приводит к почти постоянной загрузке процессора около 800%:

Я тогда воссозданного индекс с 24 черепками и времени снизился до 0.8s на 100 документов, но с более чем в два раз процессорное время:

у меня есть постоянный поток около 100 документов в секунду, а количество запросов будет расти в будущем, так что это какое-то что меня беспокоит.

Answer 1

Для того, чтобы быть понятным, вы не можете сравнивать нормальную производительность Elasticsearch на 24-ядерном Xeon с 128 ГБ памяти против производительности перколяции ES на ноутбуке - очень разные аппаратные средства и очень различное программное обеспечение.

Со многими крупными индексами (например, с 3 миллиардами документов) вы склонны либо привязываться к диску, либо к памяти при выполнении запросов. До тех пор, пока у вас будет достаточно обоих, производительность запросов может быть довольно высокой.

перколяции отличается - вы в действительности индексировать каждый документ и затем запуская каждый запрос, хранящийся в фильтровальной против каждого документа, все в в памяти Lucene индексы:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-percolate.html

перколяционные весы горизонтально и, как правило, быть привязанным к процессору - вы масштабируете его, добавляя дополнительные узлы с достаточным количеством процессоров.

С 100 документами, представленными через multi percolate api по 3000 зарегистрированным запросам percolate, вы в основном используете 300 000 индивидуальных запросов. Я ожидал бы, что это будет связано с КПК на Macbook - я думаю, вам будет лучше сравнивать это в среде с более контролируемым (отдельный сервер) и той, которую вы можете масштабировать, добавляя дополнительные узлы.

UPDATE

Так, чтобы получить лучшее представление о том, что узкое место, и как улучшить производительность вашего будет необходимо начать с меньшим количеством зарегистрированных запросов и меньшим количеством документов, в то время, а затем раздуть , Это даст вам более четкое представление о том, что происходит за кулисами.

Я бы начал с одного документа (не 100) и зарегистрировал гораздо меньше запросов, а затем выполнил серию тестов, некоторые из которых увеличили количество документов, некоторые из которых увеличили количество зарегистрированных запросов несколькими шагами, а затем пошли более 100 документов и более 3000 запросов.

Просмотрев результаты, вы получите лучшее представление о том, как снижение производительности против нагрузки - линейно с количеством документов, линейных с количеством зарегистрированных запросов.

Другие варианты конфигурации Я бы попробовал - вместо 100 документов через массив percolate api попробуйте один документ api в нескольких потоках (чтобы узнать, является ли это проблемой multi doc api). Я также попытался запустить несколько узлов в одной и той же системе или использовать несколько меньших серверов, чтобы узнать, есть ли у вас более высокая производительность на нескольких небольших узлах. Я бы также изменил объем памяти, выделенной для JVM (больше не обязательно лучше).

В конечном счете вы хотите, чтобы диапазон точек данных пытался определить, как масштабируются ваши запросы и где находятся точки перегиба.