Влияние Named Queries на производительность

Добрый день! Я хочу использовать в своих запросах Named Queries, однако протестировав на небольшом запросе, я заметил почти двукратное снижение производительности. (90-150 мс против 200-300мс с именованными запросам). Сразу скажу, что выборка идет по prefix, возвращается 50 элементов.

Я нашел тему на форуме где столкнулись с таким же поведением, однако ответа на вопрос там не содержится.

Можете объяснить/подтвердить замедление поиска с использованием Named Queries?

А сколько у вас этих именованных под-запросов в одном запросе? Пример не покажете?

Вот запрос: https://gist.github.com/tushinivan/972cde9918f779047010a4b0c5cd6576

Мне почему-то кажется, что использование Named Queries отключает какую-нибудь оптимизацию, например, без них, если документ попал по какому-нибудь условию дальнейшая проверка не идет, а с Named Queries продолжается проверка всех условий, что бы вывести весь список по которым подошел документ.

Какая версия?

6.4.3

Хранение запроса, который совпал для каждой записи, конечно, добавляет нагрузку, но увеличение времени исполнения в два раза - это как-то странно. Сколько записей этот запрос находит и как время исполнения меняется если заменить самый первый should на filter?

Если заменить первый should на filter, то запрос выдает 0 результатов за хорошее время.

Но отказаться от корневого should невозможно, т.к. таким образом мы даем пользователям возможность объединять сохраненные настройки поиска, однако после поиска понять из какого именно запроса пришли документы сложно, поэтому мы рассматриваем возможность использовать Named Queries.

Я не заметил что там два подзапроса. А если помесить этот верхний bool в другой bool с filter? Я просто хочу понять, какую нагрузку несет вычисление _score по сравнению с хранением имен.

По результатам 10 выборок среднее время практически не изменилось. Разница в 11 мс.

Я подумал, что до этого я испытывал только на простом запросе и может быть Named Queries добавляет 150 мс и это не критично, однако, сейчас я провел испытание с тяжелыми запросами и понял, что время исполнения увеличивается пропорционально количеству условий. Вот результаты которые я получил:

С Named Queries
28706 мс
22298 мс
22247 мс
24341 мс
24970 мс
avg: 24512,4 мс

Без Named Queries
15025 мс
14019 мс
14280 мс
14609 мс
10606 мс
avg: 13707,8 мс

Я понял, что для нас это неприемлемо и можно считать вопрос закрытым. Однако, я готов оказать помощь если захотите понять почему так происходит.

Есть еще несколько вопросов. Это одна нода или этот индекс распередлен? Сколько в нем шард? Как ноды сконфигурированы? Какой диск, RAM и heap для elasticsearch?

Индекс распределен по 4 нодам, конфигурация одинаковая для всех нод:

Процессор|E3-1230v6 3.5-3.9ГГц (4 ядра)
Оперативная память|64Гб
Диск 1|2000Гб NVMe
Heap для elasticsearch: 32Гб

В индексе 6 шард и 1 реплика. Все остальные параметры и конфигурация по умолчанию.