500тыс товаров

[flax]

Здравствуйте
Подскажите пожалуйста, потянет ли ocStore 3.0.3.7 из коробки 500 000 товаров или нужно будет дорабатывать как-то?
Также будет нагон трафика, достаточно атрибутов и фильтр.
Понятно что скорее всего нет, поэтому просьба посоветовать специалиста

[liveopencart]

Больше зависит от сервера, его настроек и используемых модулей.

[devimirochnik]

При таких объёмах ещё неплохо бы создать индексы модулем IMDBOptimizer (OC 3) - https://liveopencart.ru/opencart-moduli ... yi-dannyih

[nikifalex]

у вас, как я понял, еще ни сайта, ни товаров нет. а вы уже ищете специалиста по ускорению и оптимизации??

[devimirochnik]

Вообще, правильный подход: узнавать ДО, а не ПОСЛЕ

[AlexDW]

попробуйте к 100napb обратиться

[100napb]

Здравствуйте
Подскажите пожалуйста, потянет ли ocStore 3.0.3.7 из коробки 500 000 товаров или нужно будет дорабатывать как-то?
Также будет нагон трафика, достаточно атрибутов и фильтр.
Понятно что скорее всего нет, поэтому просьба посоветовать специалиста

TL;DR: из коробки потянет, но с большим трудом. Пользоваться будет по факту будет невозможно. С индексами в БД и кэшированием наиболее тяжелых блоков будет лучше. Но стабильной работы и быстрого отклика сервера без значительных переделок можно не ждать. Что бы получить действительно хорошие результаты и любовь не только пользователей, но и поисковых роботов, нужен некоторый весомый бюджет и время на доп.работы.


нюансов и правда слишком много, как и мало смысла пытаться уместить их все в какой-то развернутый ответ. Тем не менее, вот основные тезисы, основанные на личном опыте:
1. для работы фронта с таким количеством товаров, критически важным является количество товаров внутри одной категории. Если на проекте не будет жирных категорий с десятками тысяч товаров - будет проще. В противном случае, работа фильтра и банальной пагинации внутри таких категорий будет заметно тормозить даже с верными индексами.
2. очень непросто может быть с выбором модуля фильтра, учитывая что осфильтр для рф недоступен, а другие решения, насколько я помню, закубированы и\или не обеспечат должной скорости работы; осфильтр не панацея, конечно, но его код открыт в нужных местах и его хотя б можно где-то доработать\переписать
3. внутренний поиск на сайте однозначно потребует большого внимания.
4. интересным моментом так же будет периодическое обновление товаров \ цен; какие-либо интеграции-выгрузки для сторонних систем
5. Совершенно верно подметили насчет важности выбора используемых модулей и даже шаблона: далеко не все разработчики тестируют свои решения на сколько-нибудь значимом количестве товаров или хотя бы задумываются об этом. Почти наверняка что-то придется переписывать или писать самим
6. Без базовой оптимизации БД и индексов, которые могут быть проставлены хотя б тем же модулем, что советовали выше - тормозить будет вообще всё, включая админку.
7. Выбор сервера так же будет иметь большое значение. Очень важна как производительность на ядро, так и количество этих ядер: особенно если трафика будет хотя б несколько тыщ уников в сутки. "обычные" тарифы vps вам не подойдут: либо bare metal, либо современные облачные HighFreq решения. Даже имея хороший сервер, нужно грамотно настроить и затюнить окружение (конфиги nginx, php, сервера бд и прочее)

если интересно - обращайтесь. Есть примеры проектов на опенкарте и с 15к+ униками\сутки, и с 1.5млн хитов(что примерно 17 сгенерированных сервером страниц\сек) в сутки. Конечно, это скромные показатели, если сравнивать с крупными игроками рынка. Но для нашего опенкарта - вполне себе гордость.

p.s.: спасибо @AlexDw за рекомендацию.

[specialforce22]

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

А как насчет большого кол-ва категорий?
Я как-то решил раскидать все товары по по полочкам - до 20 тыщ. товаров.
Категория - город - в нем ветка.
На 70 основных категорий-городов получил более 1000 суб-категорий, то есть в каждой главной категории из 70-ти - 5-7 суб. категорий в которых тоже по несколько штук подкатегорий.
В режиме обслуживания все нормально, как только включился в публичное пространство, чрз 10 мин. сайт норовил прилечь, испытывая нагрузку.
Отключение Ocfiltre нагрузку снимало (Фильтр включен в основной и всех субкатегориях)
При этом, если все товары поместить в 1 категорию и использовать фильтр - нормально тянет.

[100napb]

Отключение Ocfiltre нагрузку снимало (Фильтр включен в основной и всех субкатегориях)
При этом, если все товары поместить в 1 категорию и использовать фильтр - нормально тянет.

если актуально - можно посмотреть и сказать наверняка.

в порядке гипотезы же:
осфильтру, как и любому другому фильтру, при работе в каждой категории нужно...гм... инициализироваться: получить список подходящих для отображения товаров, набор активных\доступных фильтров для них, а так же список всевозможных значений для отображения для каждого из этих фильтров (цвета, размеры мин-макс значения и прочее). Это самая трудоемкая операция, которая напрямую зависит от количества товаров, количества активных фильтров и разнообразия набора их значений. Обычно, после инициализации фильтр все это дело успешно кэширует и на время жизни кэша категория открывается и работает примерно так же быстро как работают getProducts и getTotalProducts в ней. И вот учитывая это все, можно предположить, что когда Вы создали 100500 категорий и разрешили фильтру работать в каждой из них - вы
а) фактически лишили его кэша, так как для каждой категории\подкатегории ключ кэша будет свой; а кэш не вечный - он инвалидируется или протухнет раньше чем пригодится хотя бы раз при такой структуре
б) заставляете фильтр работать с некоторым оверхедом, т.к. выборка уникальных товаров и фильтров с их значениями (нам ведь не нужны дубли) более сложная
по итогу, живой трафик и трафик от поисковых роботов быстренько создают ощутимую нагрузку, прыгая по всевозможным страницам категорий

[specialforce22]

 

если актуально - можно посмотреть и сказать наверняка.

Благодарю! Нее, ту конструкцию я уже переиграл, пока иду другим путем)

[nikifalex]

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

[100napb]

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

трустори ;(

альтернативный вариант: мантикора(сфинкс) или кликхаус(но там нету полнотекстового поиска). Поинтереснее агрегатов будет. Но переписывать основные методы модели фильтра =\