Александр Туниеков

Добрый день! С кешированием Я написал что у меня получилось. Кешируется массив значений фильтра и id их ресурсов. Первый запуск медленный. Это когда этот массив собирается из базы. Когда кеш массива есть показ страници и ajax-фильтрация происходит быстро. Цифры привел в статье. Сейчас не охота их заного получать.

хочется что то из коробки

Это не ко мне. Я не автор компонента. Обращайтесь к @Илья Уткин

напишите решение до чего добились в производительности

Текушее решение https://gist.github.com/touol/fd1989021270553eafb6c9540f726965
Но оно тоже не идеальное. Сильно не парился. И не понятно почему может и работать и не работать. Например, не работает и вывод дебага начал выводить вдруг заработало.
Если надо чтоб работало из коробки и так как надо, Илью долбите чтоб начал работать над улучшением mFilter2. mFilter2 — компонент платный. Пусть париться тот кто за это деньги получает.

В общем. Думаю надо тв позиции в каталоге email
при выводе

<a data-email="[[+email]]">запросить цену</a>

js берем data-email и подставляем в скрытое поле

добавить в форму скрытое поле в котором будет указан адрес получателя

А если феном использовать?

{switch каталог}
{case 'поставщик1'}
{'!formit' | snippet : ['emailto'=>'a1@b.ru']}
{case 'поставщик2'}
{'!formit' | snippet : ['emailto'=>'a2@b.ru']}
{/switch}

или заводишь тв email в каталоге. Когда показываешь каталог цепляешь тв и в формит на каждую позицию с отдельным емаил. Хотя так конечно ерунда получается.

Чтобы решать вопросы надо их вообще знать :-). Я тоже предпочитаю без решений не выступать, но эту тему поднял уже для того что разобраться в проблеме. Какие вопросы возникают? И обзор их решений. Исследование в общем. Так что ваши вопросы к mFilter2 мне интересны

39с это из-за того что на тестовой инсталяции значения из msProductData брал.

{'!mFilter2' | snippet : [
                'showLog'=>1,
                'suggestions'=>1,
                'parents'   =>  $_modx->resource.id,
                'cacheTime'=>600,
                'limit'=>100,
                'suggestionsMaxFilters'=>10000,
                'filters'=>'
                ms|size:default,
                ms|insert:default,
                ms|material:default,
                ms|style:default,
                ms|metal_color:default,
                ms|sample_material:default,
                ms|insert_color:default,
                ms|insert_form:default,
                ms|cover:default,
                ms|appointment:default,
                ms|weaving_type:default,
                ms|for_whom:default',
            ]}

В коде msearch

foreach ($filters as $table => &$fields) {
				$method = 'get' . ucfirst($table) . 'Values';
				$keys = !empty($duplicates[$table])
					? array_diff(array_keys($fields), array_keys($duplicates[$table]))
					: array_keys($fields);
				if (method_exists($this->filtersHandler, $method)) {
					$fields = call_user_func_array(array($this->filtersHandler, $method), array($keys, $ids));

То есть, значения собираются для каждой опции отдельно. 12 раз пробегается по каталогу из 11к товаров.
Блин 1 раз пробегается :-(
Вот я повернут на объективности. Обманывая других часто обманываешь и себя. А это уже чревато. Лучше честно признать ошибку и придумать новое лучшее. Это не к Вам если что. Просто лирика про себя :-).
Скорость отдачи страницы больше секунды это уже плохо. Тем более если страница для покупателей.
Спасибо что поделились своим опытом. Будет интересно взглянуть на результаты Ваших тестов.

Так есть один вариант. mFilter2 при запросе собирает информацию с выбранного каталога товаров, а не со всей базы данных. Если 200к товаров разбросанны по каталогам с 4000 товаров, то фильтрация как раз и 1-3сек будет :-)

200к товаров на 200 значений это 40 000 000 записей в базе.
В станданртной ситуации mFilter2 не может обработать 40 000 000 записей быстро.
Колитесь что Вы сделали? :-)

Просто следую правилам :-) Могу Вас на Вы называть.

Интересно что тогда влияет???
Вообще тестовая база у меня от людей которые расширили msProductData через msfieldsmanager в том числе и json полями. У меня собрать с каталога с msProductData на тестовой инсталяции уходит 39с.
У них фильтр работает по полям msOption и собрать данные уходит примерно в течении 10с.
У них шаред хостинг бегет.
То есть никаких 1-3с на 200к товаров не может быть на шаред хостингах.
Что за различия? Как-то оптимизировали базу?

как вы выражаетесь

Из правил modx.pro

Здесь все друзья и обращение на «ты» говорит только об этом. Не нужно вычурной вежливости, мы люди простые.

Я писал свой магаз тестовый с нуля и делал другую структуру данных

Поделись структурой плиз.

я тестировал 200к ресурсов с 20ю опциями

С 20 опциями или с 20 флажками?

У меня 400 флажков. А у тебя сколько?

у вас что-то не то с БД.

БД стандартное.

Manticore Search вариация Sphinx. Вчера пробовал установить OpenSearch вариацию ElasticSearch. Не поднял. Не справился с настройкой Docker :-(. Дальше без докера попробую, но пока некогда. Через неделю две пробовать буду.
Вариации Sphinx, ElasticSearch требуют vds или отдельного выделенного сервера или даже кластера серверов. Они прожорливы. ElasticSearch требует минимум 60гб на сервере. OpenSearch у меня не запускался пока размер диска на виртуалке до 100гб не поднял.
OpenSearch можно на https://aws.amazon.com/ru/opensearch-service/ подключить. Есть бесплатный тариф, но не понятно насколько его хватает. Платный тариф 1604,83 USD

заранее просчитывать все возможные пересечения для фасетного фильтра

Тут одна проблема. Не знаю точную формулу, но знаю что кол-ко комбинаций пропорционально n!.. То есть, если кол-во флажков в фильтре около 200, то кол-во всех возможных комбинаций(ты назвал пересечения, но правильней комбинации. Если я правильно понял твою мысль :-)) около 200!.. Это 7886578673 6479050355 2363213932 1850622951 3597768717 3263294742 5332443594 4996340334 2920304284 0119846239 0417721213 8919638830 2576427902 4263710506 1926624952 8299311134 6285727076 3317237396 9889439224 4562145166 4240254033 2918641312 2742829485 3277524242 4075739032 4032125740 5579568660 2260319041 7032406235 1700858796 1789222227 8962370389 7374720000 0000000000 0000000000 0000000000 0000000000 00000 комбинаций. Не знаю как это работает в Битрих, но наверно до 200 флажков они не доходят. Максимум 50. И кеш по отзывам строится у них в течении 8 часов.

Тот же подход но для Redis habr.com/ru/company/oleg-bunin/blog/316652/

Там не тот же подход. Там вариация на тему массива значений опций, как в mFilter2, только в базе Redis.

Допустим, у нас в Redis-е для Samsung-а есть вот 4 товара — 201, 202, 203, 204, а для Philips — 301, 302, 303. Ключ, соответственно, содержит ID рубрики, фильтр и вариант фильтра. Если пользователь выбирает в панели фильтров Samsung, мы запрашиваем в Redis, получаем ID товаров, отдаем их в компонент списка товаров, и наш компонент отображает 4 товара. Если пользователь выбирает еще производителя Philips, мы и делаем два запроса в Redis, берем объединение этих множеств и, соответственно, показываем семь элементов в нашем каталоге.

Для поиска советую яндекс поиск для интернет магазинов

У яндекса нет фасетного поиска. То есть фильтров нет

modx.pro/components/23283#comment-135724
Кажется ошибся. Тема для minishop2

Выяви на каком именно плагине и его код сюда.

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

да

Так плагин не надо было создовать. Надо было проверить что похожего плагина нет