Brainy Filter 4.5.1 фильтрация цен

[BestFish]

установил Brainy Filter Ultimate 4.5.1, фильтр цены перестаёт корректно работать если значение курса валюты по умолчанию выше 1, к примеру у меня курс 22 но фильтрует цену по курсу 1...
подскажите решение

ОС Версия 1.5.5.1.2

[snastik]

Поставить filterpro

Brainy filter - редкая тормозящая гадость.

[freelancer]

https://opencartforum.com/topic/43279-%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%B0%D0%BA-%D0%B2-%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%BA%D0%B5-%D1%83%D0%BA%D0%B0%D0%B7%D1%8B%D0%B2%D0%B0%D1%82%D1%8C-%D1%86%D0%B5%D0%BD%D1%83-%D0%B2-%D0%B0-%D0%BE%D1%82%D0%BE%D0%B1%D1%80/

[BestFish]

спасибо ребята, помогло:

 

 

 

еще как вариант:

Если не мультимагазин, то просто в index.php (в корне сайта) после строки:

$registry->set('currency', new Currency($registry));

 

Добавить строку:

$registry->get('currency')->set('RUB');

Это в магазине принудительно выставит валюту.

 

При таком способе корректно работает модуль автообновление цены при выборе опций

 

 

 

filterpro попробую, благодарен за совет

[snastik]

спасибо ребята, помогло:

 

 

 

 

 

filterpro попробую, благодарен за совет

 

 

Если в деталях - то brainy filter использует при фильтрации временные таблицы. Особенность работы mysql в том, что при создании временных таблиц - они получаются без индексов.

При обработке небольших массивов данных 100-200 товаров, это еще допустимо, но при обработке уже более 500 товаров, отсутствие индексируемых полей в запросах будет черевато жутчайшими томозами, оптимизировать которые в структуре Brainy фильтра - просто нет никакой возможности, кроме как заново его переписать.

[Klaus]

В 12.02.2015 в 19:46, snastik сказал:

Поставить filterpro

Brainy filter - редкая тормозящая гадость.

А разве под OC2 есть filtrpro?

[snastik]

Да есть

и не только фильетр про.

[oleksa1972]

Brainy filter - нормально работает на магазинах до 10 тис товаров.

никаких нареканий.

вот можете потестить mkshina(dot)com - сдесь 3500 карточек товаров на двух язьіках

[snastik]

7 минут назад, oleksa1972 сказал:

Brainy filter - нормально работает на магазинах до 10 тис товаров.

никаких нареканий.

вот можете потестить mkshina(dot)com - сдесь 3500 карточек товаров на двух язьіках

Он не может нормально работать! Он использует tmp таблицы. Они неиндексируемые.
Все - на этом любые возможности быстрой работы заканчиваются.

 

 

[oleksa1972]

1 минуту назад, snastik сказал:

Он не может нормально работать! Он использует tmp таблицы. Они неиндексируемые.
Все - на этом любые возможности быстрой работы заканчиваются.

 

 

)) єтого не может бьіть потому что єтого не может бьіть никогда.
(под 2 000 продаж официальньіх только через опенкарт дот ком)
dom5(dot)ua - около 7 000 карточек товаров и никаких тормозов
вьі так думаете - я иначе. дайте людям возможность сравнить и вьібрать то что больше нравится, каегоричность здесь излишняяя, как по мне. 

[snastik]

В 30.01.2017 в 09:38, oleksa1972 сказал:

)) єтого не может бьіть потому что єтого не может бьіть никогда.
(под 2 000 продаж официальньіх только через опенкарт дот ком)
dom5(dot)ua - около 7 000 карточек товаров и никаких тормозов
вьі так думаете - я иначе. дайте людям возможность сравнить и вьібрать то что больше нравится, каегоричность здесь излишняяя, как по мне. 

Ковбой который рекламировал Мальборо, умер от рака.

100 000 000 пачек сигарет в день продают. О чем мы здесь сейчас говорим?

 

[sitecreator]

В 30.01.2017 в 10:13, oleksa1972 сказал:

Brainy filter - нормально работает на магазинах до 10 тис товаров.

 

В 30.01.2017 в 10:21, snastik сказал:

Он не может нормально работать! Он использует tmp таблицы. Они неиндексируемые.
Все - на этом любые возможности быстрой работы заканчиваются.

 

Что-то я засомневался и решил проверить.

 

Есть сайт.  17000 товаров.

 

стоит обозначенный фильтр.

В одной категории 5500 товаров.  Фильтрация в этой категории занимает порядка 0.8...1 сек.

 

 

 

категория, в которой товаров примерно 250

фильтрация порядка 0.3...0.4 сек

 

 

 

 

0.3 ...1 сек - это разве тормоза?

 

это запросы, формируемые при фильтрации на странице "категории".

 

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

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

 

Я пока не вижу чтобы с таким же количеством товаров фильтр MFP справлялся бы ощутимо лучше.  Результаты на одном уровне, плюс погрешность серверов.  Может быть разница будет на 50000 шт?  или от 100000 шт. ?

 

Я читал про суровые условия вроде более 5000 шт товаров в категории.  Так я как раз и сделал подобный эксперимент. Фильтрация на уровне 1 сек. Много или мало?

 

Это самый тяжелый, занимает он 41% времени от суммы всех запросов. В нем используется now(), что не очень хорошо, т. к. средствами сервера БД такой запрос не будет кешироваться.

SELECT COUNT(DISTINCT p.product_id) AS total FROM category_path cp LEFT JOIN product_to_category p2c ON (cp.category_id = p2c.category_id) LEFT JOIN product p ON (p2c.product_id = p.product_id) LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '0' AND cp.path_id = '68'

Я вижу, что используются стандартные таблицы:

 

category_path

product_to_category

product_description

product_to_store

 

а теперь информация по запросам, в которых используются временные таблицы:

 

 

видно сколько реально времени уходит на тяжелый запрос по созданию временной таблицы = 22 мс.

 

Помимо создания и удаления временной таблицы есть еще 7 запросов, использующих эту единственную временную таблицу (других нет).

 

для примера два таких запроса. остальные 5 аналогичны по времени.

 

 

2 мс (две миллисекунды) на два запроса.  Это как-то может привести к тормозам?

еще 3 запроса на 4.5 мс

 

 

и вот последние  (в сумме 6 мс):

 

 

 

Итого, все запросы заняли время примерно 400 мс, из низ запросы, которые использовали временную таблицу заняли 34мс. При этом собственно на выборку из временной таблицы ушло 13 мс в сумме.

 

Повторюсь, что товаров 17 000 шт. и есть крупные категории, в которых есть 5000 шт товара и более.

 

Желающим могу продемонстрировать работу фильтра.

 

[chukcha]

хм.. какой памяти  какого хранения?

Временная таблица создается на момент фильтрации, и в нее попадает только product_id

 

Нужна или не нужна индексация - сомневаюсь
Потому как нужен только count(*)

Кроме того табличка то в памяти, следовательно и доступ к ней соотвествующий

 

Т.е. фильтр хорош, до определенного количества товаров, и bf, давно не смотрел его логику, также создает статические таблицы - временная таблица нужна только для рез-тов фильтра

[sitecreator]

4 часа назад, chukcha сказал:

и bf, давно не смотрел его логику, также создает статические таблицы

 

совершенно верно. все товары именно там.

и с индексами в этих таблицах нет проблем.

 

временная таблица живет недолго и занимает маленький объем.

поэтому не могу понять почему был сделан вывод о "тормознутости".

 

 

[chukcha]

Но как удобно, воспользовавшись конструктором запроса, править его, а не гадать с реплейсами

[sitecreator]

7 часов назад, nikifalex сказал:

ну отлично. только что делать с временными таблицами, когда нет лишних пары гигабайт памяти для хранения?

А если юзеров много одновременно, то где ж на всех их набрать памяти то?

И вот уже пошли данные свопиться на диск в несколько потоков.

 

Взял категорию, в которой более 10000 товаров.  Случай, практически, исключительный.

Временная таблица создается для всех товаров из категории.  И заняла она 1.5 Мб.  Это, можно сказать, предельный и редкий случай.

Для категорий, в которых 200 или даже 1000 товаров,  размер будет соответственно меньше.

 

Временные таблицы, действительно, создаются в оперативной памяти. Но даже если представить, что одновременно 10 (и более) юзеров работают, то разве проблема на VDS выделить 64М, 128М или 256М для tmp_table_size ?  Где тот реальный случай, когда памяти для временных таблиц может не хватить?

Насколько я понимаю, что если будет нехватка места в отведенной памяти (tmp_table_size ), то только тогда временная таблица будет размещена на диск.

 

 

По видимому, одной из целей создания временной таблицы было организовать быструю фильтрацию по цене, возможно еще что-то.

 

Для категории в которой 10500 товаров фильтрация по цене происходит за 1 сек

фильтрация по атрибутам 1.7 сек.  Пробовал одновременно по 3-м атрибутам.  Вторично (переход по тому же адресу или перезагрузка страницы) эта же фильтрация происходила уже за 0.9 сек.

[chukcha]

во временной таблице - да

 

Но там уже отфильтрованный результат

Все равно getProducts, а затем getProduct

[sitecreator]

47 минут назад, nikifalex сказал:

а атрибутов в этой таблице нет?

 

там (во временной) нет атрибутов. там id товара, sort_order и стоимость.

атрибуты в обычной таблице, которая имеет индексы.

Змінено 26 червня 2017 користувачем sitecreator

[chukcha]

если быть точным то там

 

                        'p.product_id',
                        'p.price',
                        'discount' => 'MIN(pd2.price)',
                        'special' => 'MIN(ps.price)',
                        'total' => 'AVG(rating)',

Т.е то же самое что и в после getProducts

[sitecreator]

Получается, что слухи о "жутчайших тормозах"  несколько преувеличены были?

Может быть такое суждение о предмете спора было рождено без должного  знакомства с самим предметом спора, т. е. с самим фильтром?

 

Категоричное мнение о "тормознутости" было как в 2015, так и в 2017-м оно не изменилось.

 

Вот и думаю чему или кому верить: то ли практическим результатам на основе товаров вполне реального магазина (не синтетических тестов), то ли заявлению авторитетных людей? 

Авторитетные люди, ведь, могут заблуждаться?

 

Я могу тоже заблуждаться. Если вы видите какое-либо несоответствие в моих выводах или некорректное сравнение, или сам эксперимент некорректный, то прошу указать, где именно я ошибаюсь.

 

Просто хотелось бы расставить точки над "I" в этом вопросе.  Поскольку в русскоязычном сообществе Opencart расползлось мнение, что данный фильтр - "гадость".

И мне представляется, что оно вводит людей в заблуждение.

 

Как и в любом модуле (фильтре), наверняка, здесь есть свои недостатки.  Я, например, пока не знаю насколько он удобен в случаях с нестандартной версткой (заказные шаблоны).

 

Тот же MFP хорошо работает с нестандартными шаблонами, как у Brainy Filter с этим обстоят дела я пока не знаю, не доводилось верстать с ним.

 

Но по скорости я не увидел проблем ни разу.  В принципе есть у меня возможность проверить его и на 50000 шт. товаров. Но думаю, что отзывчивость (скорость) фильтра будет такой же, а время загрузки/фильтрации страницы будет пропорционально кол-ву товаров в категории (и общему кол-ву).

 

Так говорим "добро" данному фильтру в больших проектах?  Я не вижу пока ограничений для проектов, как минимум, в которых до 25000 товаров. 

Согласны?

 

Если есть доводы "против", то интересно услышать.  Про "скорость" и "тормознутость" голословные заявления, думаю, что малополезны.  Интересны практические результаты, в том числе сравнение в одинаковых условиях с другими фильтрами (Meua Filter Pro, например).

[chukcha]

Я его пользую не один год

он уже из себя представляет приличную "кашу"

Там и фильтрация и на страницах производителей, и в акциях

 

Но у меня достаточно малое количество товара.
Верстка фильтра - обычная.

Поддержка достаточно быстрая, причем отвечают даже некупившему (хотя модуль куплен, но я не знаю параметров покупки), но потому что я им показал баг

Исправили на следующий день

 

 

[sitecreator]

3 минуты назад, chukcha сказал:

Я его пользую не один год

 

а я столкнулся первый раз. Причем на довольно большом кол-ве товаров.

раньше избегал из-за сложившейся неоднозначной репутации.

 

5 минут назад, chukcha сказал:

он уже из себя представляет приличную "кашу"

 

это, я так понимаю, нужно воспринимать как плюс?

 

5 минут назад, chukcha сказал:

Поддержка достаточно быстрая

 

немаловажный фактор.

 

И, насколько я понял, то к нему при желании можно еще расширение докупить для работы SEO.  В том же Mega filter pro уже включена возможность работы с SEO из коробки.

Но MFP и дороже существенно чем Brainy Filter даже в стартовой комплектации, что, как мне думается, тоже немаловажный фактор. 

 

$23 ($34 в максимальной комплектации) за фильтр, который подойдет для большинства случаев, думаю, что это и недорого. 

Т. е. может рассматриваться как достойная альтернатива фильтру MFP.

У MFP настроек вроде как побольше будет,  но они, на мой взгляд,  далеко не всем нужны в полном объеме.

 

Да и в сторону Brainy Filter посмотреть заставила ситуация, когда MFP тормозил на той же самой базе товаров.  Хотя MFP используется в составе "Plus" и устанавливался и настраивался очень авторитетными людьми.

 

Brainy Filter  показал себя вполне достойно.

 

18 минут назад, chukcha сказал:

Исправили на следующий день

 

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

 

Кстати, если смотрели сам код модуля, то какой вывод можно сделать?  На уровне "подвалов Мумбая" или на уровне "европейского программиста"?

[chukcha]

Нормальный читаемый код

   /**
     * Product limit per page 
     * @var int 
     */
    public $productsLimit = 20;

Документированый, уже о чем-то говорит

 

А это?

 

            $sql->select(array('id' => 'attribute_value_id'))
                ->from(self::ATTRIBUTE_VALUE_TABLE)
                ->where('attribute_id = ?', array($id))
                ->where('language_id = ?', (int)$this->config->get('config_language_id'));

или

 

		$sub->select(array('tr1.tax_class_id', 'rate'))
            ->distinct()
			->from(array('tr1' => 'tax_rule'))
			->leftJoin(array('tr2' => 'tax_rate'), 'tr1.tax_rate_id = tr2.tax_rate_id')
			->innerJoin(array('tr2cg' => 'tax_rate_to_customer_group'), 'tr2.tax_rate_id = tr2cg.tax_rate_id')
			->leftJoin(array('z2gz' => 'zone_to_geo_zone'), 'tr2.geo_zone_id = z2gz.geo_zone_id')
			->leftJoin(array('gz' => 'geo_zone'), 'tr2.geo_zone_id = gz.geo_zone_id')
			->where('tr2.type = \'F\'')
			->where('tr2cg.customer_group_id = ?', $this->customerGroupId);

 

Про "кашу" - в него добавлено много чего, чего нет из коробки, сортировка, акции, производители

 

 

[sitecreator]

Поставил сайт на сервер помощнее. И результат весьма достойный.

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

график говорит сам за себя.

 

Интересующимся и сомневающимся готов предоставить адрес сайта.

 

 

аналогично фильтрация по категориям, производителям, по цене

 

 

 

 

8 минут назад, chukcha сказал:

Документированый, уже о чем-то говорит

 

Согласен, хорошее дело.

 

8 минут назад, chukcha сказал:

Про "кашу" - в него добавлено много чего, чего нет из коробки, сортировка, акции, производители

 

Интересно. Надо будет самому глубже посмотреть..

[sitecreator]

решил эксперимент ужесточить.

 

есть сайт с фильтром MFP+Plus.  С кучей атрибутов, их неприлично много. И товаров в категории около 11000 Фильтрация по "толщине корпуса"  заняла 39 секунд.

 

сайт с той же самой базой товаров, но на более мощном сервере.  и на сайте дефолтный движок, нет ни одного лишнего модуля, только модуль фильтрации MFP+Plus.  та же самая фильтрация заняла 21 секунду.

 

Воспользовался я еще тем, что в настройках MFP+Plus есть "перестроить индекс " (это в "Plus").  Минут 30 работало перестроение в 5 этапов. Но прибавки к сокрости фильтрации не случилось.

 

А теперь Brainy Filter и та же самая база товаров, тоже дефолтный шаблон и только фильтр. тот же самый набор для фильтрации: атрибуты, цена, производители, наличие.  фильтрация: 7.5 секунды

 

Поставил сайт с  Brainy Filter на более мощный сервер.

результат фильтрации: 2.7 сек по атрибутам

по цене фильтрует за 1.5 сек

 

пробовал различные комбинации атрибутов + фильтрация по цене + по наличию.  результат в пределах 2...2.7 сек для категории 11000 шт. товара.

 

MFP+Plus  на том же сайте фильтрует по цене значительно дольше: в несколько раз.

 

Не знаю как объяснить, но Brainy Filter Ultimate выигрывает у MFP+Plus  при таком жестоком наборе атрибутов.

Пользовался только настройками самих фильтров.  Никакие дополнительные решения не использовал (если не считать PLUS для Meua Filter Pro).

Может быть какой секрет настройки для MFP+Plus существует для большого кол-ва товаров?

 

Я ожидал, что Brainy Filter Ultimate  проиграет, а не наоборот.

 

С другой стороны при небольшом кол-ве  (два или три) атрибутов MFP+Plus работает шустро. Его скорость сопоставима с Brainy Filter Ultimate.

 

Предполагаю, что 11000 товаров в категории, 14 атрибутов + производители + статус наличия + по цене - это жестокий перебор для любого фильтра.

 

соответственно картинки

 

 

 

 

 

 

 

 

 

 

 

 

соответственно по 14 атрибутов: