Yoda Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Подскажите пожалуйста, есть магазин, 470 000 товаров в одной категории. На выделенном сервере Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 cores) 16ГБ . У товара 20 атрибутов, - суммарно выходит порядка 10М значений атрибутов (которые надо считать на-лету). Весь каталог работает через промежуточную прокладку в виде Sphinx-демона. Файлы индекса сфинкса лежат в RAM диске в оперативной памяти. (выборка товаров в категории, подсчет количества значений атрибутов в фильтре, все все все, что можно крутится на сфинксе) После партицирования индекса на 8 частей и перенастройки конфигурации демона для использования всех 8 ядер процессора, удалось снизить время реакции фильтра с 5 до 1-1.2сек. Среднее время генерации страниц в районе 600мс. При переходе на php7.2 - будет порядка 400-450. Владелец магазина возмущается, ему не достаточно скорости. Подскажите, что можно сделать для ускорения магазина? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
PoliteX Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 сколько стоит чтобы так же тормозило ? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 6 минут назад, PoliteX сказал: сколько стоит чтобы так же тормозило ? Бесценно. Леонардо, я думаю тоже цену на Мона-Лизу сложить не мог. Но реально тупит же, а у меня уже фантазия закончилась что можно еще сделать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
zlob Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 отключить подсчет товаров в категории 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Очень смешно!! Ага. Я только что сам перечитал, что написал, звучит как жесткий троллинг, однозначно. Но это не троллинг. С момента написания поста, мне пришли в голову еще кое-какие мысли, которые мы когда-то обсуждали с маэстро @SooR, можно ведь подсчет значений атрибутов делать не по текстовому полю, а по crc32 хешу. И теоретически это может дать прирост на какие-то 20-30%. Также в целом можно отказаться от JSON-атрибутов в индексе и преобразовать все в MVA. Но мало ли, может кто сталкивался с подобным и есть еще какие умные мысли, как ускорить подсчет по 10 миллионам значений атрибутов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
n3bo Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 (изменено) а что за категории такие, по 470к? (если не секрет) Цитата Владелец магазина возмущается, ему не достаточно скорости. Скорости работы фильтра или сайта? Изменено 28 декабря 2018 пользователем n3bo Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , а лучше все на сфинкс перебросить. А, так уже на сфинксе. Тогда сделать под фильтр слейв базку. UPD. Или поэкспериментировать с выгрузкой всех индексов фильтров в память, например, в tmpfs Ёапта, и это сделали Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 9 минут назад, n3bo сказал: а что за категории такие, по 470к? (если не секрет) Скорости работы фильтра или сайта? Про категории - владелец сам расскажет, если захочет. Скорость работы как сайта так и фильтра. Так как в магазин скорее всего приедет еще столько же товаров, владелец опасается подобных писем счастья: Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 17 минут назад, n3bo сказал: а что за категории такие, по 470к? (если не секрет) Да даже шины/диски/обои.. много примеров Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: @Yoda , а лучше все на сфинкс перебросить. А, так уже на сфинксе. Тогда сделать под фильтр слейв базку Умрет mysql от таких вот запросов даже на на паре миллионов записей. SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE category_id = 20 GROUP BY txt LIMIT 100; Так что не выход. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Может добавить партиций? UPD. Sphinx третий? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: Владелец магазина возмущается, ему не достаточно скорости. Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 12 минут назад, SooR сказал: Может добавить партиций? UPD. Sphinx третий? Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. 500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 У меня несколько вариантов: 1. 3 часа назад, Yoda сказал: У товара 20 атрибутов горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 9 минут назад, n3bo сказал: а что за категории такие, по 470к? (если не секрет) Скорости работы фильтра или сайта? Про категории - владелец сам расскажет, если захочет. Скорость работы как сайта так и фильтра. Так как в магазин скорее всего приедет еще столько же товаров, владелец опасается подобных писем счастья: Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 17 минут назад, n3bo сказал: а что за категории такие, по 470к? (если не секрет) Да даже шины/диски/обои.. много примеров Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: @Yoda , а лучше все на сфинкс перебросить. А, так уже на сфинксе. Тогда сделать под фильтр слейв базку Умрет mysql от таких вот запросов даже на на паре миллионов записей. SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE category_id = 20 GROUP BY txt LIMIT 100; Так что не выход. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Может добавить партиций? UPD. Sphinx третий? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: Владелец магазина возмущается, ему не достаточно скорости. Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 12 минут назад, SooR сказал: Может добавить партиций? UPD. Sphinx третий? Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. 500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 У меня несколько вариантов: 1. 3 часа назад, Yoda сказал: У товара 20 атрибутов горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: @Yoda , а лучше все на сфинкс перебросить. А, так уже на сфинксе. Тогда сделать под фильтр слейв базку Умрет mysql от таких вот запросов даже на на паре миллионов записей. SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE category_id = 20 GROUP BY txt LIMIT 100; Так что не выход. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Может добавить партиций? UPD. Sphinx третий? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: Владелец магазина возмущается, ему не достаточно скорости. Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 12 минут назад, SooR сказал: Может добавить партиций? UPD. Sphinx третий? Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. 500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 У меня несколько вариантов: 1. 3 часа назад, Yoda сказал: У товара 20 атрибутов горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: Владелец магазина возмущается, ему не достаточно скорости. Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 12 минут назад, SooR сказал: Может добавить партиций? UPD. Sphinx третий? Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. 500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 У меня несколько вариантов: 1. 3 часа назад, Yoda сказал: У товара 20 атрибутов горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 12 минут назад, SooR сказал: Может добавить партиций? UPD. Sphinx третий? Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: Пускай аргументирует чем не устраивают <= 500ms, нужно спорить с его возмущениями, т.к. результат адекватный. 500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 У меня несколько вариантов: 1. 3 часа назад, Yoda сказал: У товара 20 атрибутов горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 3 часа назад, Yoda сказал: При переходе на php7.2 - будет порядка 400-450. А при переходе на 7.3 350-400 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Opencart 3.x Opencart 3.x: Настройка и оптимизация Помогите ускорить магазин и MegaFilter Pro
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 1 минуту назад, SooR сказал: У меня несколько вариантов: 1. горизонтальная модель с динамическими колонками 2. второй серв под фильтр без панелей и прочего, только минимум пакетов 3. свой фильтр 1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 4 минуты назад, SooR сказал: 4. Пре-кэширование всех категорий и первый уровень фильтров. По логике, последующие (2+) уровни должны отрабатывать быстрее за счет сужения выборки Вот это здравая мысль. 2 минуты назад, SooR сказал: А при переходе на 7.3 350-400 Ioncube ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 @Yoda , делай crc32, как самый быстрый способ проверить. 1 минуту назад, Yoda сказал: 1 - не совсем понял Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 24 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 0 комментариев 5 362 просмотра Sha 25 апреля 2020 [Поддержка] Route board - Профилирование, помощник в оптимизации сайта! Автор: Sha, 25 апреля 2020 почалося! profiler (и ещё 39) Теги: почалося! profiler без гмо debug board route system audit helper help time оптимизация попугаи скорость ускоритель модуль список timeline debuger прочее module график charts page google speed speeder дополнения модули расширения аудит техническая проверка сайта быстрый opencart быстрый 100% debugger профілювання профиль профилирование 18 ответов 2 548 просмотров Sha 18 января 2022 SmartBoost - ускоритель opencart Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 0 комментариев 2 111 просмотров Vladzimir 19 мая 2023 Модуль SmartBoost - ускоритель opencart [Поддержка] 1 2 Автор: Vladzimir, 21 июня 2023 speed boost (и ещё 1) Теги: speed boost booster 35 ответов 1 067 просмотров Vladzimir 18 июля 2023 [Поддержка] Оптимизация и настройка скорости загрузки магазинов Автор: snastik, 27 июня 2017 turbo pagespeed (и ещё 1) Теги: turbo pagespeed время загрузки 10 ответов 3 672 просмотра Magazinufedora 26 апреля 2018 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу.
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 Только что, SooR сказал: @Yoda , делай crc32, как самый быстрый способ проверить. Не product_id filter_id filter_value_id 1 1 1 1 1 2 1 2 3 1 2 4 1 3 5 а product_id filter_id_1 filter_id_2 filter_id_3 1 [1,2] [3,4] [5] условно. Если нет мультиатрибутов, то еще быстрее без json Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
SooR Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 Вперёд Страница 1 из 2 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 29 минут назад, SooR сказал: Если сильно заморочиться, можно использовать метод перерасчета пар Кантора для исключения дополнительного поиска по attribute_id, преобразовав два id в один: attribute_id && crc32(text) => [какой-то один id] Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Guava Опубликовано: 28 декабря 2018 Поделиться Опубликовано: 28 декабря 2018 если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Yoda Опубликовано: 28 декабря 2018 Автор Поделиться Опубликовано: 28 декабря 2018 11 минут назад, Guava сказал: если у товара 20 атрибутов - все ли они нужны для сортировки фильтром? Если нет - или убрать как таковые эти атрибуты из стандартных атрибутов, или вынести их (ненужные типы атрибутов) в отдельную таблицу и выводить только на карточке товара, как информацию. Таким образом поиск по ненужным атрибутам происходить не будет. Не зная сферу этого магазина сложно сказать, но думаю там 5-7 атрибутов по которым нужна сортировка - остальное представляет собой целую кипу данных в таблице. Наверное наивный совет да? В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Рекомендованные сообщения