при отправке 200-300 запросов в сек среднее время отдачи 0.5 сек
если брать отдельные запросы (причем 200-300 не выключаем) и отправлять по одному, то они выполняются за 0,1 сек
Так а что тут странного? Concurrency 200-300 отличается таки от concurrency 1 в 200-300 раз и просадка latency в 5 раз вроде нормальна при этом.
Создали распределенный rt индекс (состоит из 8 штук)
…
Sphinx работал на plain индексах.
…
disk_chunk : 15
…
Ядер проца 32 шт
В sphinx до конца непонятно как было: то ли один всего индекс, то ли 8 шардов и соответственно 8 индексов, но в данном случае в Manticore у вас получается 15 чанков * 8 шардов = 120 чанков (по сути plain индексов), а ядер 32. И concurrency пикует до 200-300. Думаю, в вашем случае можно попробовать чанка по два на шард оставить, если вообще не один. Попробуйте optimize index IDX option cutoff=2 для каждого шарда сделать (в test environment) в качестве эксперимента. Тут нужно выбирать исходя из того, чего хочется: низкий latency в пиках - тогда при таком concurrency поменьше чанков оставлять или вне пиков - тогда можно и побольше. В общем нужно экспериментировать.
Fields specified in field_weights option not found: [section_hz]
Это не филд у вас, а атрибут:
section_hz integer
и можете дать ссылку где почитать насчет дисковых чанков? за что они отвечают, что дают? т.е. их физику.
Да всё просто: RT индекс - это по сути просто обёртка, которая скрывает в себе plain index’ы + дистрибутивный индекс + RAM chunk. Инсертите в RT - сперва всё аккумулируется в RAM chunk’е, когда rt_mem_limit переполняется - сбрасывается в дисковый чанк, т.е. по сути создаётся plain index.
также интересует FACET что это? на что влияет? в моем понимание фасетный индекс ускоряет запросы но тут не могу разобраться для чего?
Просто такая группировка. Почитайте в доке - Manticore Search Manual: Searching > Faceted search
Посмотрите курс - Manticore Faceting