В этой статье мы тестируем, как работают percolate‑запросы в Manticore Search и Luwak.

Введение

Недавно мы тестировали производительность Percolate Queries в Manticore Search и Elasticsearch . Сегодня мы рассматриваем Luwak, движок хранимых запросов, основанный на библиотеке поиска Lucene.

Когда мы разрабатывали Percolate Queries, мы изучали существующие движки, реализующие эту функцию. Бенчмарки, предоставленные Flax (авторами Luwak), выполненные здесь , заставили нас протестировать Manticore против Luwak, так как он превосходил Elasticsearch. В первых тестах мы обнаружили, что Luwak был быстрее нашей реализации, что помогло нам выявить места, которые можно оптимизировать, и улучшить (во многих случаях значительно) производительность Percolate Queries в Manticore Search.

Настройка

Бенчмарки были проведены Станиславом Клиновым, одним из старших разработчиков ядра Manticore Search, а также давним разработчиком Sphinx Search.

• последняя версия Manticore Search

• Luwak 1.5.0 с веткой HTTP‑сервера - https://github.com/tomatolog/luwak/tree/luwak-server

• http://github.com/tomatolog/luwak_tests для данных, источника запросов и скрипта отправки запроса демону через HTTP

• http://github.com/Ivinco/stress-tester для запуска бенчмарков

Мы взяли ветку luwak-server и объединили её с веткой luwak-1.5.0, чтобы иметь и HTTP‑сервер, и последнюю версию Luwak.

В предыдущих тестах с Elasticsearch мы использовали только запросы из 4 слов (2 MUST и 2 NOT). Теперь мы попытались воспроизвести условия бенчмарка , проведённого Luwak (против Elasticsearch). Мы рассмотрели 3 типа хранимых запросов:

• запросы из 7 слов, из которых 5 являются MUST и 2 — NOT

• запросы из 120 слов, из которых 100 являются MUST и 20 — NOT

• запросы из 20 wildcard‑слов (каждое состоит из суффикса длиной 4 символа)

Наша цель — выполнять обратный поиск, используя отдельные и пакетные документы. Percolate‑запросы запускаются либо одним поисковым воркером, либо несколькими воркерами (для тестирования режима конкурентности).

Percolate‑запросы выполняются через HTTP‑API, поэтому мы объединили ветку Luwak, содержащую HTTP‑сервер, с последним стабильным кодом.

Тесты

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

5x MUST + 2x NOT из 100 тыс. сохранённых запросов

Средние задержки также растут быстрее у Luwak, когда мы начинаем пакетировать документы.

Чтобы нагрузить движки, мы добавили несколько конкурентных поисковых воркеров, осаждающих движки. Luwak работает несколько лучше при пакете из 100 документов, так как Manticore замедляется, но всё равно примерно в 2 раза медленнее.

Средние задержки следуют той же схеме: у Luwak более высокие задержки, когда документы пакетируются.

100x MUST + 20x NOT из 100 тыс. сохранённых запросов

Этот случай сильно ударил по Luwak.

20 wildcard‑слов длиной 4 символа из 5 тыс. сохранённых запросов

Во время тестов мы обнаружили проблему с производительностью (ещё не исправленную) в Manticore при использовании хранимых запросов с wildcard‑ами и пакетных документов. Пропускная способность падает, когда мы добавляем несколько документов в пакет. Luwak, в отличие от предыдущих тестов, работает плохо в непакетном режиме, но при пакетировании документов слегка опережает Manticore.

При атаке движков конкурентными воркерами нет явного победителя.

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

Заключение

Для сохранённых запросов с несколькими терминами без подстановочных знаков единственный случай, когда Luwak сопоставим с Manticore, — это режим без пакетной обработки. Как только мы начинаем пакетировать документы, Manticore значительно превосходит Luwak по пропускной способности, а средние задержки обычно составляют половину от Luwak.

Худший сценарий для Luwak — когда сохранённые запросы содержат более сотни терминов без подстановочных знаков. Даже в режиме без пакетной обработки Manticore более чем в 3 раза быстрее, достигая около 20‑кратного ускорения в случае 10 пакетированных документов. У Luwak также наблюдаются чрезвычайно высокие задержки, когда документы пакетируются для сопоставления.

Для сохранённых запросов с терминами, содержащими подстановочные знаки, явного победителя нет. Luwak в некоторых случаях работает немного лучше. На нашей стороне известна ошибка (фильтры отклонения Bloom работают не так, как ожидалось), которая влияет на производительность. Лучший случай для Luwak был при пакетировании 20 документов с одним запущенным поисковым рабочим, когда он был почти в 2 раза быстрее, но в остальных случаях прирост гораздо меньше или Manticore немного опережает.