Ниже — реальные замеры на двух разных стендах. Free-версия тестировалась на скромном железе 2014 года, PRO-версия — на современном сервере с эмбеддингами. Все цифры приблизительные и зависят от CPU, RAM, диска и загрузки системы.
Замер через wrk на стенде AMD Ryzen 7 5700X, 64 ГБ RAM, NVMe SSD. 1000 случайных поисковых фраз из демо-каталога, limit=10, нагрузка: 2 потока, 10 соединений, 30 с.
Конфигурация
QPS
Средняя latency
p50
p99
Production-конфиг (по умолчанию)
~242
~41 мс
~40 мс
~83 мс
Tuned-конфиг (отключены дорогие фичи поиска)
~664
~15 мс
~14 мс
~30 мс
Tuned-конфиг дает примерно в 2,7 раза больше QPS за счет отключения дорогих search-time фич. Это максимум throughput; production-конфиг сохраняет более высокое качество поиска.
Что именно изменено в tuned-конфиге и зачем
Параметр
Production
Tuned
Почему влияет на скорость
max_candidates_for_fuzzy
500
100
Меньше fuzzy-кандидатов — быстрее пост-фильтрация
use_unified_search
true
false
Нет лишнего Boolean OR по exact-полям (code, art, barcode)
transliteration_enabled
true
false
Не генерируются транслитерированные варианты токенов
enable_critical_token_filtering
true
false
Отключен пост-фильтр по «критичным» токенам
extended_search_enabled
true
false
Не ищем по extra-полям (color, material и т.д.)
enable_deep_1c_parsing
true
false
Нет препроцессинга 1С-запросов
min_token_match_ratio
0.5
0.0
Не отсекаем результаты по минимальному покрытию токенов
candidate_multiplier
2
1
Меньше кандидатов на ранжирование
logging.level
info
warn
Меньше логов на каждый запрос
console_enabled / file_enabled
true
false
Нет pretty-вывода и записи логов на диск
Побочный эффект: может снизиться recall на опечатках, разных падежах и поиске по атрибутам. Используйте tuned-конфиг только как потолок производительности или для нагрузочных тестов, где важен максимум RPS.
Для небольших каталогов (\<1000 товаров): уменьшите `pro.background.lance_write_flush_timeout_ms` до 1000–2000 мс, иначе большой буфер будет ждать таймаута.
В PRO-режиме семантический поиск работает через ONNX Runtime. По умолчанию активна модель bge-m3, также из коробки настроена e5. Оба варианта конфигурируются через config.toml: вы указываете путь к model.onnx, размерность вектора и стратегию объединения токенов.
нужна многоязычность (русский + английский + артикулы);
ресурсы сервера позволяют — 20+ ГБ RAM и SSD.
Выбирайте e5-small, если:
основной режим — hybrid с сильным полнотекстовым сигналом;
критичны скорость индексации и размер диска;
запросы в основном точные или содержат артикулы/штрихкоды;
сервер ограничен по RAM.
Про разреженные векторы: для `bge-m3` есть поддержка sparse-векторов (параметр `enable_sparse`). В наших тестах подключение sparse-ветки не дало прироста точности в hybrid-режиме, поэтому по умолчанию она выключена.
Как это читать: HTTP-ответ на `/add` остается мгновенным (\~0.1 мс на товар), потому что эмбеддинги строятся в фоновой очереди. Основное время загрузки большого каталога — именно фоновая индексация векторов.